из требований - цветной, и не глючит в линуксе. но главное чтоб можно было доливать чернила. я столнулся с тем, что в продаже есть доливные катриджи но подходящие к ним принтера в разумной ценовой категории(т.е. дочке котиков печатать) отсутствуют. а в неразумной я pantum возьму лазерный за те же деньги. а без долива чернил, вообще нет смысла вообще брать что-то типа pixma
Тут недавно в голосовалке про IPv6 минимум двое его упомянули. Воткнул, посмотрел. Соображения на вскидку:
Может быть полезен, если у меня в локалке нет доступа к DHCP-серверу, чтобы фиксированные IP моим машинам прописать. Исчезающе редкий случай: к домашнему роутеру доступ есть всегда, а на работе кто бы вам позволил что попало на комп устанавливать.
За пределами локалки в теории смысл тот же – стабильные IP, но на практике ИМХО всё плохо настолько, что почти бессмысленно:
Собственных ресурсов внутри сети так мало, что их можно не брать в расчёт.
Позиционирует себя как zero-conf, но при этом – отказ от персистентного кеширования и автовыбора списка пиров. Дескать, программно это трудно сделать оптимально. Beg pard’n, а руками не трудно? Программно они могли бы пинги до пиров потихоньку в фоне мерять, как всякие другие делают (уж не помню кто именно, может dnscrypt-proxy; UPD: telegram/android тоже), и выбирать лучшие. А сейчас – я захожу через VPN(!) в реестр публичных пиров, прописываю руками как дурак себе в конфиг три первых из России, у которых week uptime 100%, и если они сдохнут – мне без VPN новых пиров не узнать, т.к. внутри сети даже сраного зеркала этого публичного реестра нет. «В ковид вы не могли купить маску без маски, а теперь не можете подключить VPN без подключения к VPN.» (c) Ну и нахрена оно такое надо?
Частный случай – использование для обхода блокировок. Допустим, хочу я с телефона дёргать комп. А на телефоне нынче минимум пол-суток – белый список. Если и есть в ygg-сети адреса, затесавшиеся в этот белый список, то с момента ручного ввода случайных пиров эту дрянь надо держать на телефоне работающей фоном (т.е. выжирающей проц и трафик) непрерывно – чтобы найдя их, она их потом не потеряла. Пробовать уже заломало. (UPD: А хотя попробовал. На телефоне включаю wifi, включаю ygg – есть соединение; через пару минут выключаю wifi – вручную введённые публичные пиры пропадают, и вместе с ними вся ygg-сеть отваливается. «Некросивое, не покупаем.» (c))
Где я не прав?
В debian есть юзер с зашифрованной через fscrypt домашней папкой. Вот только после завершения сеанса папка остаётся частично разлоченной. Если зайти под рутом и попробовать залочить её вручную, то обычно пишет что папка используется другим юзером, но иногра всё же блокирует. Похоже проблема кроется в иксах, и в частности в LightDM/XFCE, т.к. если логиниться через консоль то всё гуд. Гугление и арчвики не помогли - в дебиан всё это как-то кастомизировано сделано.
Привет.
А можно сделать ввод markdown текста слева, а предпросмотр справа на широких мониторах? Широкие — это не мобильные.
На мобильных оставить как есть, с вкладками. Было бы намного удобнее писать с компа, всё равно поле ввода почти весь экран по ширине.
Только тем, у кого есть время. Есть однонапрвленный упорядоченный граф (надо найти все пути из a в z, но, видимо, программно):
a → b, c, d, z
b → d, e, f, z
c → d, e, f, z
d → e, f, z
e → f, z
f → g, h, j, z
g → h, i, j, z
h → i, j, k, z
i → j, k, l, z
j → k, m, z
k → l, n, o, z
l → m, z
m → n, o, z
n → o, z
o → p, z
p → q, z
q → r, z
r → s, z
s → t, u, z
t → u, v, z
u → v, w, z
v → w, z
w → x, y, z
x → y, z
y → z
z → (нет исходящих)
Свой результат пишу сразу ( даже не уверен, что 100% правильный, но все ж…): Все пути:
22061
Все пути в массивах. Вывод кода: https://filebin.net/ysidtdizjge50kjh
Код для проверки: https://gitflic.ru/project/dcc0/mix-c-89-php/blob?file=allways_more_20k.php
Сабж.
Немного предыстории. Захотелось пощупать stable-diffusion-webui(нейронка для генерации картинок), а онf тестировался только с Debian 11 (Bullseye) разработчиком из стабильных дистров.
Install script for stable-diffusion + Web UI
Tested on Debian 11 (Bullseye), Fedora 34+ and openSUSE Leap 15.4 or newer.
INCOMPATIBLE PYTHON VERSION
This program is tested with 3.10.6 Python, but you have 3.13.5.
If you encounter an error with "RuntimeError: Couldn't install torch." message,
or any other error regarding unsuccessful package (library) installation,
please downgrade (or upgrade) to the latest version of 3.10 Python
and delete current Python and "venv" folder in WebUI's directory.
Fedora Workstation 44. Стандартная программа Подключения или Remmina. Другие компы на Windows и Android подлючаются без проблем. Порт - 3389 Выдает ошибку - Аунтификация не прошла. The connection failed at TLS connect.
Chat GPT не помог…)))
Просто интересно, ведь не может такого быть, что вот вы увидили впервый никсы и вот прям с первого же дня сказали - это моё ?
Кто пользуется китайским или японским языком, как вы вводите иероглифы, произношения которых не знаете? Перепробовал много чего, но всё в итоге требует произношения. Кроме Kanjipad, но он мой почерк вообще не понимает.
P.S. Совсем забыл: есть поиск по радикалам в Kiten. Но там нет сокращённых вариантов ключей (например, 氵 и 氺 вместо 水). И рисовать было бы быстрее.
Какие приложения в современном десктопном Линуксе позволяют опознать нарисованный иероглиф или найти его по ключам? Без подключения к интернету.
UPD2: Вот тут хорошо распознаёт: https://kanji.sljfaq.org/draw.html, есть куча наворотов: Undo, опциональный учёт порядка и направления черт, несколько удобных реализаций поиска по радикалам (включая с учётом положения). Ищу оффлайн-версию. — Всё закрыто, оффлайн-версия недоступна.
https://www.freebsd.org/security/advisories/FreeBSD-SA-26:26.ktls.asc
Механизм аналогичный линуксовому copyfail.
Но переживать особо не стоит - баг в ktls, который выключен по-дефолту (sysctl kern.ipc.tls.enable=0).
Баг в KTLS, при этом KTLS включён по умолчанию начиная с релиза 15.0, в более ранних - выключен и можно не переживать. Проверить тут: sysctl kern.ipc.tls.enable.
Для новости слишком поздно - объявили 9 июня.
Как лучше всего изолировать приложения в Linux — чтобы они не могли получать доступ ко всему домашнему каталогу пользователя? Допустим, приложение ставится через pip или npm, загружает множество зависимостей, вряд ли можно быть уверенным в том, что с ними никогда ничего не случится в плане безопасности, и хочется ограничить доступ таких приложений только к тому, что им реально нужно для работы. Какой вариант лучше всего выбрать?
Важно, чтобы приложение могло работать с графикой и звуком, и чтобы это не создавало угроз при работе с другими приложениями.
Погуглил, вроде бы лучший в плане простоты и надёжности вариант — это landrun?
В теории вирус можно запустить в Wine ,не станет ли тогда мой пк источником заразы для устройств с Windows?
Доброго дня!
В очередной раз пытаюсь разобраться с короутинами из C++20. Среди того, что не понимаю, есть один момент, который можно обозначить как «идеология обращения с асинхронными сущностями». Попробую пояснить о чем речь.
Большинство примеров использования короутин демонстрируют co_await в одну операцию. Что-то вроде:
auto socket = co_await socket_factory::connect(ip);
co_await socket.send(request_packet);
auto reply = co_await socket.receive();
...
Но, насколько я смог понять, в реальности за co_await something() стоит два шага:
Поэтому, при желании, программист может переписать строчку co_await socket_factory::connect(ip); в более развернутом виде:
// Получили в свое распоряжение короутину connect.
auto connect_task = socket_factory::connect(ip);
... // Тут курим бамбук.
// И только сейчас толкаем ее на выполнение.
auto socket = co_await connect_task;
Теперь к сути вопроса.
Допустим, у меня есть очередь сообщений и я хочу сделать к ней async_receive, который бы представлял из себя короутину. Т.е. что-то вроде:
async_receive_task_t async_receive(message_queue_t queue) {
... // Какие-то действия с co_yield/co_return.
}
И чтобы к этому async_receive можно было применять co_await:
auto msg = co_await async_receive(commands_queue);
Сейчас у меня есть мысль, что в async_receive сразу при входе можно делать попытку чтения из очереди. И если очередь не пуста, то немедленно доставать сообщение оттуда.
Такой «энергичный» подход вроде как хорош тем, что не нужно тратить время если очередь сообщений не пуста. Сразу же внутри async_receive получаем сообщение, наш awaiter_t об этом узнает и вернет true из await_ready. Соответственно, не придется делать попытку приостановить ту короутину, в которой обратились к async_receive.
Однако, меня смущает потенциальная возможность вот какого сценария:
auto receive_coro = async_receive(command_queue); // (1)
// Теперь у нас на руках есть короутина async_receive, но в приостановленном
// состоянии.
...
... // Еще какие-то действия.
...
if(something_went_wrong) return; // Дальше не идем.
// Только сейчас нам нужно сообщение из очереди.
use(co_await receive_coro); // (2)
При «энергичном» подходе если в command_queue было сообщение, то это сообщение будет извлечено в точке (1). Однако, если дело до точки (2) не дойдет, то сообщение будет потеряно.
Что мне кажется неправильным. Ведь co_await-а не было. А значит и явной попытки взять сообщение в обработку не было.
Возможно, правильным был бы «ленивый» подход. Сама короутина async_receive создавалась бы в приостановленном состоянии, а первая попытка чтения из очереди была бы в awaiter_t::await_suspend. И чтобы awaiter_t::await_suspend возвращал true только если очередь пуста и нужно приостанавливаться до появления в ней сообщений (соответственно, если в awaiter_t::await_suspend сообщение удалось взять, то возвращается false).
Чтобы было еще более понятно, допустим, что есть синхронный аналог, sync_receive, который всегда возвращает взятое из очереди сообщение (и блокируется если очередь пуста). В случае синхронного кода можно написать:
auto msg = sync_receive(queue);
log(debug, "msg extracted, type={}", msg->type());
...
if(something_went_wrong) return;
...
log(debug, "start processing msg");
use(msg);
log(debug, "complete processing msg");
И по логам мы точно отследим когда сообщение было взято из очереди. Даже если оно не было обработано из-за раннего return-а, то судьба сообщения становится понятна.
В случае же с async_receive написать в таком же стиле не получится. Т.е.:
auto receive_coro = async_receive(queue); // (1)
...
if(something_went_wrong) return;
...
auto msg = co_await receive_coro;
log(debug, "msg extracted, type={}", msg->type()); // (3)
log(debug, "start processing msg");
use(msg);
log(debug, "complete processing msg");
Если сообщение реально было изъято из очереди в точке (1), но до точки (3) мы не дошли, то следов сообщения у нас не будет. Получится, что иногда сообщения теряются, но непонятно где и как.
Собственно весь мой вопрос – это попытка понять, как в мире современного С++ принято относится к коду вида:
auto task = some_call(); // (1)
...
auto result = co_await task; // (2)
Я вижу два возможных и вполне себе логично обоснованных варианта:
И нужно выбрать какой из этих вариантов взять за основу для async_receive чтобы это вызывало как можно меньше «WTF?»
Всем привет!
Сразу оговорюсь, что я не размещаю вакансию и прочее. У моих знакомых, которые работают в мед.учреждении, постоянно проблема найти человека, который бы занимался как бэкапами, прокладкой сетей, так и взаимодействием с разработчиками медицинского ПО, чтобы они со своей стороны исправляли косяки и делали доработки. В общем (в моем понимании), нечто среднее между сисадмином и эникеем (надеюсь, это не звучит обидно). Проблема в том, что HeadHunter испортился не только для разработчиков, но похоже что и для работодателей: учреждение никого не может найти и уже думают о том, чтобы обращаться в колледжи и на биржу труда, поэтому стало интересно: а где сейчас стоит искать сисадминов и размещать вакансии?
IRC, Jabber, P2P протокол eDonkey2000, NNTP, FTP, электронная почта. Есть бесплатный http://eternal-september.org/ для NNTP, но это мало кого привлекает. Перевелись задроты компьютерные да программистких дел мастера?
Я просыпаюсь, делаю кофе, и начинаю поиск новостей, их иногда очень много, примерно понимая что будет «ненужно», отфильтровываю. Хотя иногда мне самому интереснее выбрать другое.
По тому что решил выбрать, формирую тексты, проверяю ссылки, часто их приходится уточнять, часто попадаются кривые речевые обороты, всё это правится. Вставляю картинки, если они есть в исходных текстах. Последнее время, замечаю, тексты выдаваемые идеально с первого раза стали получаться чаще. Стиль речи в ИИ текстах улучшается.
На новость уходит минут по 15-20, думаю это не много, 2-3 новости, и я перехожу к другим личным делам. Что-то могу пропустить, что-то не считаю речевой ошибкой. Что-то кажется мне понятным, но лучше перевести не могу, иногда оказывается что понимаю оригинал лучше чем ИИ, тогда вношу правку.
Не понимаю чего @dataman лепит мне какие-то злые рожи, что его коробит? Что за психи-то, а именно так это выглядит со стороны. Если не может помочь, можно не мешать.
Вижу, что большинство положительно реагирует на появление новостей и обсуждает их по существу, делясь положительными реакциями.
Иногда находится 1-2 человека разводящего под текстами флуд. Всё, всё сопротивление индустрИИализации, но тревожная тенденция заключается в том, что часто из-за флуда 2-3 человек, на старте половина комментариев от них и не по делу. И подобные комментарии начинают воспроизводить сами себя.
Мне не понятны все эти инициативы со стороны единственного человека, с концентрацией именно на моём кейсе. Не много-ли чести? А именно:
score за «плохо написанные» тексты. А судить об этом будет dataman, главный филолог ЛОРа, зарплату он мне что ли платит, чтобы наказывать?Прошу не воспринимать как наезд, хочу чтобы было понятно, я со своей стороны тоже многое делаю. Как говорят в ИТ, «это не бесплатно», имея ввиду накладные расходы, даже в, казалось бы, элементарных кейсах.
Когда я запускаю Steam (установлен через apt) у меня появляется чёрный экран монитора на несколько секунд с надписью «нет видеосигнала, переход в режим ожидания», после этого открывается Steam.
Видеокарта: NVIDIA GeForce RTX 3060 Драйвер: NVIDIA-SMI 580.159.03 CUDA Version: 13.0
Я пробовал переустановить steam и при установке мне выдало надпись:
32-bit Nvidia driver (nvidia-driver-libs:i386) required
This computer appears to be using the Nvidia binary graphics driver (the nvidia-driver package).
Steam is a 32-bit program, so running it on this computer requires the 32-bit versions of the Nvidia libraries, even if all the games you will run via Steam are 64-bit. Please install the nvidia-driver-libs:i386 package.
For full functionality (including Vulkan), also install the libraries listed as Recommends in the nvidia-driver-libs:i386 package.
If you are using a legacy version of the Nvidia driver such as nvidia-legacy-340xx-driver, please install the corresponding 32-bit legacy package, for example nvidia-legacy-340xx-driver-libs:i386.
При попытке установить эту библиотеку мне пишет:
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово
Пакет nvidia-driver-libs:i386 недоступен, но упомянут в списке зависимостей другого
пакета. Это может означать, что пакет отсутствует, устарел или
доступен из источников, не упомянутых в sources.list
E: Для пакета «nvidia-driver-libs:i386» не найден кандидат на установку
Но как я понял другие основные 32-ух битные библиотеки для стима у меня установлены
Перехожу по ссылке из поиска куда-то, а там
Ошибка при установлении защищённого соединения
ищу где кнопка добавления исключений, но её почему-то нет. Читаю внимательнее что написано
При соединении с otvet.mail.ru произошла ошибка. Сертификат узла был отозван.
Код ошибки: SEC_ERROR_REVOKED_CERTIFICATE
Вобщем, там GlobalSign и он отозван. На главной у них выпущеный сегодня утром сертификат от какого-то греческого CA, а в других местах видимо забыли переделать.
Почитал, оказалось что GlobalSign запланировал отзыв сертификатов и вообще всех российских клиентов. А чего новости на лоре не было или даже темы в толксах? Только про LE.
Привет, ЛОР.
Пишу программу на C++ без GUI, но с работой по сети, в частности, надо принимать и обрабатывать UDP-пакеты. Не так часто приходится начинать проекты с нуля, поэтому хочется сделать красиво.
Пока в голову приходят варианты:
<sys/socket.h> и всё такое). Гарантированно будет работать, но как-то в плюсовой программе… ну неопрятненько, что ли. Хотя возможно, это мои личные тараканы.Что бы выбрали вы в 2026 году? Пока склоняюсь в сторону Boost.Asio, но может, уже что-то более стандартное и надёжное появилось?
Стандарт (по предварительной информации) C++17 (но буду уточнять этот момент).
Пытаюсь обновить Astra Linux c 1.7 на 1.8 через
sudo astra-full-upgrade force
вроде все скачалось, предлагает обновить и перезагрузиться, но после перезагрузки загружается старая версия 1.7. В чем может быть дело? Лог astra-upgrade.log
2026-06-18-12.31.00: Loading installer configs
2026-06-18-12.31.00: Loading file /usr/lib/python3/dist-packages/astra_installer/installer.conf.yaml
2026-06-18-12.31.00: Loading file /usr/lib/python3/dist-packages/astra_installer/configs/common.conf.yaml
2026-06-18-12.31.00: command: uname --machine
2026-06-18-12.31.00: x86_64
2026-06-18-12.31.00: Loading file /usr/lib/python3/dist-packages/astra_installer/configs/installer/amd64/conf.yaml
2026-06-18-12.31.00: Loading file /usr/lib/python3/dist-packages/astra_installer/configs/reserved-usernames.yaml
2026-06-18-12.31.00: Loading file /usr/lib/python3/dist-packages/astra_installer/../astra_upgrade/configs/upgrade.conf.yaml
2026-06-18-12.31.01: Loading file /var/cache/astra-upgrade/upgrade.report.yaml
2026-06-18-12.31.01: command: uname --machine
2026-06-18-12.31.01: x86_64
2026-06-18-12.31.03: command: dpkg-query -l astra-upgrade-config | grep ii
2026-06-18-12.31.03: ii astra-upgrade-config 1.8.1.12 amd64 Config of target release for astra-upgrade-console and astra-full-upgrade
2026-06-18-12.31.03: command: dpkg-query -Wf '${Package} ${Version}
' | grep astra-upgrade-config
2026-06-18-12.31.03: astra-upgrade-config 1.8.1.12
2026-06-18-12.31.03: Loading file /usr/share/astra-upgrade/target.conf.yaml
2026-06-18-12.31.03: Loading file /usr/share/astra-upgrade/current.conf.yaml
2026-06-18-12.31.03: Create systeminfo settings...
2026-06-18-12.31.03: command: modprobe efivars >/dev/null 2>&1 ; /bin/true
2026-06-18-12.31.03: command: uname --machine
2026-06-18-12.31.03: x86_64
2026-06-18-12.31.03: Create installer locale setting...
2026-06-18-12.31.03: Create system locale setting...
2026-06-18-12.31.03: command: locale
2026-06-18-12.31.03: locale: Cannot set LC_CTYPE to default locale: No such file or directory
2026-06-18-12.31.03: locale: Cannot set LC_MESSAGES to default locale: No such file or directory
2026-06-18-12.31.03: locale: Cannot set LC_ALL to default locale: No such file or directory
2026-06-18-12.31.03: LANG=en_US.UTF-8
2026-06-18-12.31.03: LANGUAGE=
2026-06-18-12.31.03: LC_CTYPE="en_US.UTF-8"
2026-06-18-12.31.03: LC_NUMERIC="en_US.UTF-8"
2026-06-18-12.31.03: LC_TIME="en_US.UTF-8"
2026-06-18-12.31.03: LC_COLLATE="en_US.UTF-8"
2026-06-18-12.31.03: LC_MONETARY="en_US.UTF-8"
2026-06-18-12.31.03: LC_MESSAGES="en_US.UTF-8"
2026-06-18-12.31.03: LC_PAPER="en_US.UTF-8"
2026-06-18-12.31.03: LC_NAME="en_US.UTF-8"
2026-06-18-12.31.03: LC_ADDRESS="en_US.UTF-8"
2026-06-18-12.31.03: LC_TELEPHONE="en_US.UTF-8"
2026-06-18-12.31.03: LC_MEASUREMENT="en_US.UTF-8"
2026-06-18-12.31.03: LC_IDENTIFICATION="en_US.UTF-8"
2026-06-18-12.31.03: LC_ALL=
2026-06-18-12.31.03: Create layout setting...
2026-06-18-12.31.03: Create timezone setting...
2026-06-18-12.31.03: Create ntp settings...
2026-06-18-12.31.03: Create hostname setting...
2026-06-18-12.31.03: command: hostname
2026-06-18-12.31.03: w8715dep27.ft.kk
2026-06-18-12.31.03: Create datetime setting...
2026-06-18-12.31.04: Creating upgrade info setting...
2026-06-18-12.31.04: Create kernel setting...
2026-06-18-12.31.04: command: apt-cache search linux- | grep Complete
2026-06-18-12.31.04: linux-5.10 - Complete 5.10 Linux kernel
2026-06-18-12.31.04: linux-5.10-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-5.10-hardened - Complete hardened Linux kernel
2026-06-18-12.31.04: linux-5.15 - Complete 5.15 Linux kernel
2026-06-18-12.31.04: linux-5.15-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-5.15-hardened - Complete hardened Linux kernel
2026-06-18-12.31.04: linux-5.15-lowlatency - Complete lowlatency Linux kernel
2026-06-18-12.31.04: linux-5.4 - Complete 5.4 Linux kernel
2026-06-18-12.31.04: linux-5.4-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-5.4-hardened - Complete hardened Linux kernel
2026-06-18-12.31.04: linux-6.1 - Complete 6.1 Linux kernel
2026-06-18-12.31.04: linux-6.1-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-image-5.10-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-image-5.10-hardened - Complete hardened Linux kernel
2026-06-18-12.31.04: linux-image-5.15-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-image-5.15-hardened - Complete hardened Linux kernel
2026-06-18-12.31.04: linux-image-5.15-lowlatency - Complete lowlatency Linux kernel
2026-06-18-12.31.04: linux-image-5.4-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-image-5.4-hardened - Complete hardened Linux kernel
2026-06-18-12.31.04: linux-image-6.1-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-image-latest-generic - Complete generic Linux kernel
2026-06-18-12.31.04: linux-latest - Complete latest Linux kernel
2026-06-18-12.31.04: linux-latest-generic - Complete generic Linux kernel
2026-06-18-12.31.04: Create security settings...
2026-06-18-12.31.04: command: /usr/sbin/astra-mic-control status
2026-06-18-12.31.04: ACTIVE
2026-06-18-12.31.04: command: /usr/sbin/astra-mac-control status
2026-06-18-12.31.04: INACTIVE
2026-06-18-12.31.04: command: /usr/sbin/astra-digsig-control status
2026-06-18-12.31.04: INACTIVE
2026-06-18-12.31.04: command: /usr/sbin/astra-secdel-swapwiper status
2026-06-18-12.31.04: astra-secdel-control: INACTIVE
2026-06-18-12.31.04: astra-swapwiper-control: INACTIVE
2026-06-18-12.31.04: command: /usr/sbin/astra-nobootmenu-control status
2026-06-18-12.31.04: INACTIVE
2026-06-18-12.31.04: command: /usr/sbin/astra-ptrace-lock status
2026-06-18-12.31.05: INACTIVE
2026-06-18-12.31.05: command: /usr/sbin/astra-sudo-control status
2026-06-18-12.31.05: ACTIVE
2026-06-18-12.31.05: command: /usr/sbin/astra-nochmodx-lock status
2026-06-18-12.31.05: INACTIVE
2026-06-18-12.31.05: command: /usr/sbin/astra-interpreters-lock status
2026-06-18-12.31.12: INACTIVE
2026-06-18-12.31.12: command: /usr/sbin/astra-macros-lock status
2026-06-18-12.31.17: INACTIVE
2026-06-18-12.31.17: command: /usr/sbin/astra-console-lock status
2026-06-18-12.31.17: INACTIVE
2026-06-18-12.31.17: command: /usr/sbin/astra-hardened-control status
2026-06-18-12.31.17: INACTIVE
2026-06-18-12.31.17: command: /usr/sbin/astra-ulimits-control status
2026-06-18-12.31.17: INACTIVE
2026-06-18-12.31.17: command: /usr/sbin/astra-noautonet-control status
2026-06-18-12.31.18: INACTIVE
2026-06-18-12.31.18: command: /usr/lib/python3/dist-packages/astra_installer/configs/security/astra-installer-localtime-control / status
2026-06-18-12.31.18: command: /usr/sbin/astra-commands-lock status
2026-06-18-12.31.18: INACTIVE
2026-06-18-12.31.18: command: /usr/sbin/astra-format-lock status
2026-06-18-12.31.18: ACTIVE
2026-06-18-12.31.18: command: /usr/sbin/astra-mount-lock status
2026-06-18-12.31.18: INACTIVE
2026-06-18-12.31.18: command: /usr/sbin/astra-shutdown-lock status
2026-06-18-12.31.18: INACTIVE
2026-06-18-12.31.18: command: /usr/sbin/astra-sumac-lock status
2026-06-18-12.31.18: INACTIVE
2026-06-18-12.31.18: command: /usr/sbin/astra-sysrq-lock status
2026-06-18-12.31.18: ACTIVE
2026-06-18-12.31.18: Create mode setting...
2026-06-18-12.31.18: command: astra-modeswitch get
2026-06-18-12.31.18: 1
2026-06-18-12.31.18: Creating disk setting...
2026-06-18-12.31.18: Loading installer configs
2026-06-18-12.31.18: Loading file /usr/lib/python3/dist-packages/astra_installer/installer.conf.yaml
2026-06-18-12.31.18: Loading file /usr/lib/python3/dist-packages/astra_installer/configs/common.conf.yaml
2026-06-18-12.31.18: command: uname --machine
2026-06-18-12.31.18: x86_64
2026-06-18-12.31.18: Loading file /usr/lib/python3/dist-packages/astra_installer/configs/installer/amd64/conf.yaml
2026-06-18-12.31.18: Loading file /usr/lib/python3/dist-packages/astra_installer/configs/reserved-usernames.yaml
2026-06-18-12.31.18: Create storage setting...
2026-06-18-12.31.18: Creating upgrade storage setting...
2026-06-18-12.31.23: Create partitioning template...
2026-06-18-12.31.23: Create package settings...
2026-06-18-12.31.23: Create extended settings...
2026-06-18-12.31.23: command: dpkg-query -Wf '${Package} ${Version}
' | grep astra-full-upgrade
2026-06-18-12.31.23: astra-full-upgrade 2.1.0
2026-06-18-12.31.25: command: dpkg-query -Wf '${Package} ${Version}
' | grep astra-console-upgrade
2026-06-18-12.31.25: astra-console-upgrade 2.1.0
2026-06-18-12.31.25: command: dpkg-query -Wf '${Package} ${Version}
' | grep astra-upgrade
2026-06-18-12.31.25: astra-upgrade 2.1.0
2026-06-18-12.31.25: astra-upgrade-config 1.8.1.12
2026-06-18-12.31.25: astra-upgrade-current-config 1.7.6.15
2026-06-18-12.31.25: command: dpkg-query -Wf '${Package} ${Version}
' | grep python3-astra-installer
2026-06-18-12.31.25: python3-astra-installer 2.0.7+ci1
2026-06-18-12.31.25: command: dpkg-query -Wf '${Package} ${Version}
' | grep astra-full-upgrade
2026-06-18-12.31.25: astra-full-upgrade 2.1.0
2026-06-18-12.31.25: command: dpkg-query -Wf '${Package} ${Version}
' | grep astra-console-upgrade
2026-06-18-12.31.25: astra-console-upgrade 2.1.0
2026-06-18-12.31.25: Launch mode: force. Stage: verification
2026-06-18-12.31.25: command: mount /dev/sda1 /boot/efi
| ← предыдущие | следующие → |