В данный момент мы ведём работу немного в другом направлении - lxc-desktop. С точки зрения надёжности это тоже лучше. Вы можете запустить и одновременно работать во всех десктопах кальки и убивать их по одному
Да. Если это будет настроено также, как сделано в Qubes OS, то это будет шикарно. Я имею ввиду потенциал неубиваемой системы, когда основа обновляется совсем уж незначительно и проблем там много не бывает. А всё остальное из основы можно действительно прибить.
Помню, как-то я говорил что-то о docker, но, насколько я понимаю, LXC - более гибкое решение, если оно правильно настроено…
Александр - я против обсуждения в telegram
Да, соглашусь в этом с Тимофеем. Сайт он как-то нагляднее, занимаешься своими делами, отвечаешь, когда время есть. А Телеграм… не понимаю я всеобщего им увлечения, у меня и нет его даже… вон, в кальку пора вместо pidgin’а TOX ставить, но никак не Телеграм…
Конечно, в кальке светлого будущего будет сайт с встроенным мессенджером, а так же поддержка рассылки в соцсети блога, новостей и т.д. Тогда соцсети станут выступать в роли агрегаторов со своим сообществом и поддержкой. Пока же за неимением сайта и имея большую потребность в контакте с пользователями, а так же для обкатки новых идей мы стали использовать телеграм. Понятно, что в телеграме не всё сообщество, а каких-то 200 человек. Тем не менее это позволяет поддерживать связь с переводчиками, локализаторами, блогерами, дизайнерами и всеми людьми, которые помогают нам развивать и улучшать систему, в любой момент имея возможность связаться с каждым в режиме реального времени. Это эффективно.
Простой пример. Сегодня создали группу для выкладывания скриншотов. Казалось бы что тут такого? В Фейсбуке иностранцы постят скриншоты, я их перекидываю в ВК. Почему бы не создать группу в Телеграм? В итоге в течение двух часов в неё вошло более 20 человек. Стало понятно, что это не просто скриншоты, это ещё и обмен информацией по используемым настройкам, темам, обоям и т.д. Сразу же можно спросить у автора что он использовал. Можно это получить здесь? Сейчас нам надо перенести материал в новую вики с форума, как тут можно попросить авторов это сделать? Диалогом через форум с каждым? На это уйдёт уйма времени, эффективность будет ничтожная.
По поводу lxc-desktop. В течение некоторого времени мы ведём работу по поддержке запуска десктопа из контейнера. Это не отдельные приложения, а запуск системы. Один из плюсов как раз отказоустойчивость. Задача базовой системы Calculate Linux Container просто загрузиться. Десктоп разворачивается в контейнере, может иметь копии, может одновременно быть запущено несколько копий. Перезагрузка Calculate Container Dekstop происходит практически мгновенно. Ещё одно преимущество заключается в том, что к ПК можно подключать несколько мониторов со своими системами работающими из контейнеров. Ресурсы пробрасываются. Дистрибутивы могут быть установлены разные, с разным софтом, разных версий.
К сожалению мы столкнулись с одной проблемой, связанной с нестабильной работой приложений запущенных по RDP из терминального Windows сервера. Абсолютно без понятия с чем это связано. Из-за этой проблемы пришлось откатывать установки у нас в офисе на неопределённый срок.
мы убираем из бинарного ядра calculate-sources патчи uksm и muqss, оставляя их USE-ами.
Александр, пожалуйста, уточните, прописывание этих флагов - это в итоге выбор соответствующего бинарного пакета ядра (по аналогии с флагом pae), или речь все же идет о пересборке с учетом этих флагов.
Хочу предложить предложение
В цикле очередного обновления апдейтер удаляет “устаревшие” пакеты, коль скоро таковые к моменту обновления найдутся. Предлагаю вывести из сценария удаления “устаревших” пакетов Ядра, которые уже установлены и работают в системе и предоставить возможность пользователю самостоятельно принимать решение об удалении ядер.
В пользу такого решения говорит ситуация с ядром 4.14.8. Имеющееся в системе ядро 4.9.67 позволило безо всяких зависаний и паник обсуждать проблему с 4.14.8.
после обновления на 4.14.8 машина стала виснуть на старте сразу после загрузки initrd, не успев даже загрузить фреймбуферную заставку. Предыдущее ядро 4.9.67 работает без нареканий.
После обновления на 4.14 проблема осталась, начал рыть, оказалось что проблема в драйвере AMDGPU - он собирается (по крайней мере ошибок при emerge не вываливает), но с новым ядром , судя по всему, не работает.
Отключил всю графику при загрузке, в текстовом режиме ядро нормально загружается, но при попытке загрузить иксы вываливает крэшдамп.
То есть получается, при попытке загрузить первоначальную консольную заставку проприетарный видеодрайвер просто вешает систему.
мы убираем из бинарного ядра calculate-sources патчи uksm и muqss, оставляя их USE-ами.
Александр, пожалуйста, уточните, прописывание этих флагов - это в итоге выбор соответствующего бинарного пакета ядра (по аналогии с флагом pae), или речь все же идет о пересборке с учетом этих флагов.
Есть бинарный пакет muqss без pae для десктопа. Вообще комбинаций из разных комбинаций флагов много. Поддерживать все варианты бессмысленно. Судя по опросу оценить могут далеко не все.
так что, в 4.14.9 снова не будет uksm и muqss?
Оставили опционально USE-флагами. Uksm на сборочном сервере выдавал ошибки в лог. Оставлять такой патч по умолчанию в системе слишком опрометчиво.
В цикле очередного обновления апдейтер удаляет “устаревшие” пакеты, коль скоро таковые к моменту обновления найдутся. Предлагаю вывести из сценария удаления “устаревших” пакетов Ядра, которые уже установлены и работают в системе и предоставить возможность пользователю самостоятельно принимать решение об удалении ядер.
Сейчас логика работы утилиты обновления такова, что она никогда не затрёт ядро с которого вы загрузились. Мне кажется этого более чем достаточно. Для подстраховки есть другие инструменты, в т.ч. второй раздел с предыдущей версией системы.
Вчера, 27-12-2017, обновил ядро до 4.14.9 (4.9.67 по прежнему и к счастью, в системе). Сегодня загрузил стейдж от 27-12 и попытался записать DVD+RW.
Так вот, с ядром 4.14 я четыре раза пытался сделать эту запись и все четыре раза получал зависание. Не скажу насчет ядра, по крайней мере светодиоды на клавиатуре не мигали, но выполнить какие-то действия на рабочем столе не получалось. Помогала только кнопка рестарта на системном блоке.
Загрузился с ядром 4.9.67 и с первого раза записал образ.
после обновления на 4.14.8 машина стала виснуть на старте сразу после загрузки initrd, не успев даже загрузить фреймбуферную заставку. Предыдущее ядро 4.9.67 работает без нареканий.
После обновления на 4.14 проблема осталась, начал рыть, оказалось что проблема в драйвере AMDGPU - он собирается (по крайней мере ошибок при emerge не вываливает), но с новым ядром , судя по всему, не работает.
Отключил всю графику при загрузке, в текстовом режиме ядро нормально загружается, но при попытке загрузить иксы вываливает крэшдамп.
То есть получается, при попытке загрузить первоначальную консольную заставку проприетарный видеодрайвер просто вешает систему.
