mayton2019

Чтобы просто почитать память процесса - ему можно послать сигнал SIGQUIT и он должен ссыпать самого себя в дамп файла. Это законный метод. Программист пытается понять state процесса.

Все прочие методы должны вызывать настоящий ужас спецов по инфо-безопасности. Кому понадобилось изменять чужие процессы? Какой юзкейс?

Для новичка лучше не использовать LVM. Помимо того что это легаси софт она еще и не самостоятельый. Все равно нужно затаскивать конкретные файловые системы. Это создает определенную путацицу и вообще - правильно использовать утилиты lvcreate/vgcreate/pvcreate и не напортачить при этом - большое искусство. Готов спорить что с 1 раза ничего не выйдет.

+1 к btrfs.

Вообще лучше взять какой-то старый диск который не жалко и на нем потренирваться а потом уж на нужных файлах.

Да что за преподаватель такие задачи придумывает? Неужели не мог что-то полезное выдавить? Наверное нужно поменять ядрос ОС. Перекомпилировать по сути. Задача КМК нетривиальная для какой-то лабы. Тут - скорее можно получить кучу новой побочки даже не дойдя до решения лабы. Вобщем проще занести деньги на кафедру.

Капс печатает логи ошибок здесь /var/log/cups
Посмотри какие там последние события.

Если чистка файлов идёт на регулярной основе - то имеет смысл сделать эту папку диском и подключать через fstab. Для чистки - umount + mkfs + mount. Займет секунды.

Ещё - обратить внимание на тип файловой системы. Например zfs удаляет медленно. Возможно стоит перейти на ext4.

Подобные вещи надо делать через некое распределённое хранилище типа Zookeeper которое хранит сведенья о топологии серверов. Если пришло глобальное событие - то взвести флажок в зу-кипере типа "трафик на таком -то хосте" появился. А отвествтеный демон или скрипт будет заглядывать в этот флажок и принимать решения. Такая буферизация спасет вас от "множественных сбросов кеша" которых вам не избежать без буферизации и дедупликации событий. Говорю как разработчик поскольку в распределённых системах - это самая частая ошибка. Неучет фантомных и ненужных событий.

Это переменная которая хранит код ошибки предшествующей команды. Обычно 0 - это ок. А другое число говорит о неудаче.

Скорее всего надо запустить компиллятор и оценить масштаб трагедии. И после этого писать новое сообщение в тостер.

Я сильно сомневаюсь в наших "прогнозах" здесь в условиях отсутствия информации.

А разве это возможно? Git позволяет изменить только последние коммиты, схлопнув их в 1 коммит (amend).

Или можно полностью создать новый репо и перенести туда все изменения по 1 штуке.

Сделайте дополнительный appender который пишет в json формате и настройте на эти файлы кибану. И тогда будет решена проблема многострочности.

Принты. Или наблюдения.
1. Цикл где идет merge двух векторов - тривиален. Слабым местом может быть функция резерва памяти, которая по разному реализована в win/Linux. Я не утверждаю что в linux она плохая. Возможно просто звёзды сошлись так что page или другие свойства ос по отношению к аллокаций стали неблагоприятны.

2. Что там с разрядностью 32/64? Надо проверить. Что с железом? Не пытается ли автор нас обхитрить, запуская все это на разном железе. Даже ничтожные различия в размере кешей L1 могли тут сработать.

3. Версии STL. Автор использует не сырые указатели а итераторы. Причем хитрые. Какая там логика на инкремент и на разыменование под капотом.

Чтоб отбросить мои предположения полностью - предлагаю этот цикл (предположительно самый горячий код со слов автора) переписать на указатели без STL.

4. Опции GCC надо посмотреть. Оптимизацию подвигать. O1, O2.

Автор, твои логи ничего не показывают.
Интервал между событиями - менее 1 минуты.
Это не то за что надо бороться.

Готовое решение уже предложил Александр.
А автор, если хочет решать его именно в среде Libre office (кстати уточнить что имелось в виду, writer или calc) должен изучить basic, который встроен в эту среду и использовать его.

По моему скромному мнению решение таких задач в офисах - это никому не нужная блажь.

Профессионалам это никогда не интересно. А на уровне кухонного рецепта - решение в 1 посту уже готово.

Я вот не пойму. Автор что на 5 языках пишет? Полиглот прям.

По теме. Лет 20 назад у линукса был ужасный UI. И установка драйверов видяшек - это челендж еще тот был.
Сегодня он достаточно прилизан. И шрифты хорошие есть.

Да. Докер неудобно использовать на Windows.

Да. Имеет смысл в наше время практиковаться в командной строке Linux/Unix/BSD чтоб иметь в крайнем случае заработок девопса если будет создан ИИ и всех программистов уволят. Или если ты будешь стар и глуп и негоден к современной скрам аджайл разработке. Или если твоей бабушке надо будет настроить файрвол или почту. Или просто если будешь перед друзьями "понты колотить". Например mp3 плеер запустить из консоли. Или хакнуть сайт своей школы. Вобщем много плюшек. Думай.

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

Ну а если серъезно - то - этот вопрос решал еще лет 20 назад один еврейский дядечка. Филипп Циммерман. Он написал опенсорцный продукт PGP (Pretty Good Privacy) и в виде книги сорцами опубликовал его для использования. Включил туда набор шифров с военным уровнем разрядности (там кажется до 4096 бит ключи) и сделал реализацию в виде консольных утилит. Предполагается что вы будете слать емейлы шифрованные этой утилитой. Или через любой канал который текстовый кидать шифрованные мессаги.

Я сам не админ. Но причастен к сектору эксплуатации инфо-технологий на предпрятиях. Разрабатывал и внедрял.

Мне кажется вопрос не так звучит. В наше время ценится не эникейщик а автоматизатор. Поэтом Линукс админ должен уметь автоматизировать рутину. Тоесть не "стучать по клавишам" а уметь взяв bash/python сделать рутинное действие на множестве файлов или конфигураций.

По командам - не скажу. Но мне кажется тут вопрос не в командах (nslookup/dig) а в понимании сетей и протоколов. В понимании верхнего уровня архитектуры. И если этот уровень понятен - то неважно какая команда. Это тоже самое что строителя спрашивать знает ли он "уровень" или "отвес."

На вопрос автора нет ответа. По крайней мере в том виде как он описал. Надо смотреть конкретные графические приложения и багтрекер по ним. В Windows - единый API графики - Win32GDI и под него пишут всё оконное. Direct* - для игровой графики. Это упрощает техподдержку. А в Linux есть целый зоопарк графических сред (Gnome, Kde, XFCE) и эти графические среды тоже несут свой багтрекер и их тоже надо рассматривать как источник возможной проблемы. +Состояние драйверов NVidia оставляет желать лучшего под Linux. Они не всегда актуальны.

Принципиально эта задача не имеет решения. Если юзер хоть как-то на экране видит видео - то считайте что он его уже качает. Вопрос технического и программного оснащения - это вопрос времени.

DRM не поможет если плеер уже транслирует драгоценное видео с релизом вашего сериала - то вы можете купить HDMI-recorder и спокойно писать цифровое видео прямо с выхода видеокарточки.

Вывод - контент будет украдет полюбому. Поэтому лучше не парьтесь ерундой. А если у вас что-то реально хорошее - продавайте его как Megogo продает сериалы за небольшую плату.