Ubuntu Linux исполнилось 20 лет!

xDDDDDDD

Ну да, с какого раза ты поймёшь что кроме корпоративного энтерпрайза есть ещё частные ПК и там не нужно в онлайне анализировать состояние системы и даже высчитывать милисекунды финального этапа загрузки?

Тем временем, оно наисало мне 2*8Мб журнала всего лишь загрузившись в десктоп. А за полчаса работы там стало 2*8,35Мб.

Поставь лимит на 32 мегабайта и пиши в память.

Какую задачу это решит кроме более быстрой перезаписи ненужного мусора на диске?

Делай правильно

Правильно - это отключить ненужную функцию, жрущую ресурсы. Ты вот до прерываний генератора случайных чисел добрался, а бревна в глазу похоже не заметил. Полный идиотизм - полировать ненужную функцию, жрущую ресурсы, чтобы она как бы работала, но при этом как бы не работала.

Он и работает.

Нет. Если выключенный сервис самопроизвольно включается - ну явно что то пошло не так. Если его нельзя отклчать - нужно сказать об этом при попытке выключения.

Просто некоторые сервисы нужны.

Некоторые, но точно не этот. Проверено.

А чо, пусть тебе ядро без всего этого статикой собирают.

Хорошая кстати идея. Так быстрее и проще. Инитрд нужен если у тебя шифрование корня, но мне это не нужно.

Как только они дропнут поддержку старого железа

А зачем им снижать аудиторию, если для этого буквально просто не надо ничего делать?

это перестанет быть проблемой

С чего бы это? Им совершенно некуда девать ресурсы на встраиваемой системе? Вот скажи, зачем роутеру обязательная поддержка cgroups в ядре? А тот же журналд? Могу поспорить что задействование нетворкд только добавит им геморроя, у них и так более гибкая и налаженная система конфигурирования сети.

Лично у меня роутер с 16Мб оперативки и «надо бы там системд запустить» это самая идиотская причина для обновления железа какую можно придумать. Кстати, для понимания: обновление роутера на абсолютно любой другой не решит никакой практической задачи и не улучшит ни одной характеристики ни на 1%. Может быть лет через 5... Но это не точно.

Мы говорили о том, что journald дает возможность ИЗ КОДА легко прочитать лог, это буквально обращение к базе данных.

Да, но ахрена козе баян? Одному юзеру из 100 раз в год может понадобится заглянуть в логи роутера. Для этого не надо писать кода и даже включать мозг избыточно: все пользовательские роутеры управляются со страницы веб-интерфейса, там же встроена вкладка с логами. Десять кликов не уходя из окна браузера и ты читаешь логи. Твой код в лучшем случае сделает задачу дольше и сложнее.

Тебе не надо десять раз писать парсеры и самому агрегировать логи из кучи файлов, journald уже это сделал.

open-wrt/dd-wrt тоже это сделали причём ещё тогда, когда системд ещё не появился - у них уже всё было написано, распаршено и прекрасно работало на таком железе, где современный системд просто не сможет запуститься. Самое главное здесь то, что журналд ничем не может улучшить их работу. Всё, совершенство достигнуто ещё до того как он родился, расходимся и не гадим - есть более важные другие задачи.

Поставь себе нормальную ось, типа арча, в котором systemd/journald интегрированы правильно, и посмотри, как это работает у нормальных людей.

Чобы что? Потратить пару месяцев до того, как система начнёт работать? Уже работает. Чтобы после этого прийти к тому, что журналд мне не нужен? Так он и сейчас не нужен. Всё что у меня не работает или глючит - прошивко-драйверо-аппаратные проблемы и он тут в принципе помочь не может.

Шок! — информация об управлении сервисами находится в справочных страницах утилит управления сервисами! — вы бы никогда не догадались, понимаю.

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

Вы в состоянии привести фрагмент, на который ссылаетесь, или так и будете продолжать извиваться, как уж на сковороде?

Ты уже приготовил $500?

Во-первых, это бред сивой кобылы.

Во-первых, клоун, эта проблема должна решаться снапшотами. Точка. Либо у тебя надежная файловая система с гарантиями, либо гарантий нет вообще никаких, и все эти пляски не имеют смысла, потому что прерывание dpkg оставит систему в неконсистентном состоянии. Я не понимаю, почему я должен объяснять настолько очевидные вещи.

Во-вторых, вы так удобно проигнорировали все остальные пункты, говорящие об убогости pacman в сравнении с «взрослыми» менеджерами пакетов.

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

Метрика «достаточно хорошо», вообще-то, является ключевой при проектировании архитектуры. Можно упарываться до позеленения и получить переусложненную систему, а можно решить проблему на достаточном уровне, а высвобожденные ресурсы отправить на доработку и сопровождение других частей дистрибутива.

For shell scripts this means that you almost always need to use set -e

almost

Я понял тебя. Знаешь, что побудило написать меня ту заметку? После того, как я напоролся на эту проблему в арче и пошел разбираться в дебиан, я напоролся на эту проблему и там. Так что грош цена твоей браваде про школьные поделки.

Видите, как в новой версии утверждения скромно появилось «…апстримным 6.x», да? ng-tools5 очень даже является апстримным… хоть больше и не развивается там.

Нет, это просто умилительно :) Только истинный фанат дебиана будет считать апстримом репозиторий, в котором разработка остановилась еще 11 (!) лет назад, в то время, как существует живое продолжение разработки на гитхабе. Вот на гитхабе - апстрим. А то, что привел ты называется мертвый репозиторий с архивным кодом.

В общем, ничего нового, всё как всегда…

Не знаю, у меня с первых версий убунты работало чуть больше, чем всё.

А Мандрива = Мандрейк + Коннектива - стыдно этого не знать.

Тем не менее, они этого не отрицают. Просто, может, не договаривают. Ничего страшного тут нет. МакОС тоже нигде не говорит, что она бдсм на самом деле.

Это хорошо. Не все добрались до этого момента.

Ну, я тоже пробую всякое. Астра суть есть тот же дебиан. Ещё тут в треде партиусх посоветовали, гляну. )

Текущие античиты работают только по одной причине - у пользователя нет доступа к железу. Как только этот пользователь получает контроль - тут же вся «безопасность» и рушится.

M$ вполне могут запретить ядерные античиты, вот только они в таком случае предложат API для проверки tampered статуса - по сути DeRbMo на уровне железа/OS. В macOS такое уже реализовано, но редко используется.
SIP отключил - всё, trusted статус потерян, считаем устройство взломанным.

В линуксе такое по дефолту невозможно - пользователь сам управляет системой, поэтому в праве на своём десктопе делать что вздумается вкл. установку драйвера на уровень ядра вместе с античитом. На Windows такой финт не проходит - для этого нужно подписать драйвер, если у корпораций с EAC/BattlEye для этого денег полно, то у читеров ну… вряд ли даже за деньги выйдет. Не зря ж вся эта кривая малварь требует SecureBoot/TPM.
Остаётся только уязвимости в железе искать (взламывать собственное устройство, дивный новый мир), либо использовать unfixable дырки - DMA через Thunderbolt/PCIE и прочее. Но это уже экзотика.

Кажется, проще не играть в онлайндрочильни, я вон в RDR2 кайфую и в кубач в мультиплеер гоняю..

TL;DR античиты на линуксе невозможны из-за слишком большой открытости оного.
Дек тоже открыт, единственное, что валв могут сделать - распространять подписанное ядро с включёнными модулями античитов - при этом доступ в систему будет ограничен. Запустился с обычным ядром - доступ есть, онлайндрочилен нет.

P.S. нативные античиты на линуксе менее эффективны по сравнению с виндовыми аналогами про причинам выше, просто пока читеры не особо пользуются этой дырой - так что выгоднее таки разрешить пользователям Deck играть.

Ладно, согласен, размаскировал, перезагрузился, журнал появился, есть информация. И десяти лет, ять, не прошло…

А потом окажется, что остальные твои проблемы решаются точно так же.

Нахрена мне избыточно сложный комбайн для простых действий?

Чтобы не изобретать велосипеды.

А для больших систем нужны другие средства.

Оказалось, что не особо-то нужны, и путем переконфигурирования один раз написанного компонента можно получить нужное поведение что для большой системы, что для встраиваемой. Унификация.

А ты точно уверен, что он не является обёрткой над системдешным компонентом, оставленным просто для удобства привычных админов?

Абсолютно, я читал исходник. Это буквально свой «старый-добрый костыль».

Ну да, с какого раза ты поймёшь что кроме корпоративного энтерпрайза есть ещё частные ПК

Пользвателю частного ПК вообще плевать на то, пишется ли у него журнал. А если ты пошел журналы отключать, потому что в твоем мировосприятии они НИНУЖНЫ, то у тебя определенно на среднестатистический ПК, а уникальная снежинка. Назвался груздем - полезай в кузов.

Какую задачу это решит кроме более быстрой перезаписи ненужного мусора на диске?

Сохранение лога на случай, если у тебя что-нибудь сломается. Логи, в общем-то, для этого и нужны.

Правильно - это отключить ненужную функцию, жрущую ресурсы.

Нет. Правильно - это сохранять логи в память, если много логов не нужно. Потому что логи всегда нужны в ретроспективе. Когда они понадобятся, окажется, что они отключены.

Ты прям как еще более упоротый вариант Саахрикту: «не всем нужны логи, некоторые хотят гадать на кофейной гуще», «не всем нужна работающая система, некоторые хотят сидеть и созерцать в черный экран».

А зачем им снижать аудиторию, если для этого буквально просто не надо ничего делать?

Совместимость тащит за собой технический долг по сопровождению и отжирает ресурсы разработчиков. Когда добавляются новые фичи, надо убедиться, что они работают под старыми ОС. NetBSD, например поддерживает все мыслимые архитектуры, и это их киллерфича. OpenBSD на спарки уже не встает, не говоря уже о FreeBSD.

Им совершенно некуда девать ресурсы на встраиваемой системе?

Оперативная память нужна, чтобы размещать в ней софт. Скажем, на роутере. Если ее очень много - допустим, больше половины - то можно упростить себе жизнь, используя более фичастый компонент, который будет кушать чуть больше памяти, но при этом давать большее удобство для разработчика в плане взаимодействия с этим компонентом. Нет никакого смысла экономить ее ради сферической экономии, потому что на ней все равно ничего другого, кроме роутерного софта, запускаться не будет.

Лично у меня роутер с 16Мб оперативки и «надо бы там системд запустить» это самая идиотская причина для обновления железа какую можно придумать.

Ну да, это твой частный случай. А у меня стоит Dream Machine Pro, на нем 4 гига оперативы и почти полноценный линукс, разрабы поставили побольше памяти, чтобы сделать очень фичастый и удобный софт, снизив при этом застраты на разработку: железо покупается один раз, а софт поддерживается всю жизнь.

На PiKVM у меня вообще полноценный линукс, даже с systemd journald, прекрасно работает на 256 мегабайтах оперативы - это удобно и для меня, и для пользователя, при этом система вместе с моим софтом кушает где-то 100 мегабайт.

А 16Мб - это наерняка какой-то бородатый легаси из древних времен. OpenWRT, конечно, молодцы, что все еще тянут это, но техдолг будет расти и в какой-то момент поддержку закопают.

Для этого не надо писать кода и даже включать мозг избыточно: все пользовательские роутеры управляются со страницы веб-интерфейса, там же встроена вкладка с логами.

Я тебе объясняю, как с точки зрения разработчика устроена вкладка с логами. Чтобы ты мог посмотреть веб-страницу, сервис для этого должен кто-то написать. А проще всего это сделать, если у тебя сервисами управляет systemd, а логи собирает journald. В противном случае аггрегатор логов придется велосипедить самому, чем все разработчики встраиваемых ОС и занимались до того, как появился journald.

Чобы что? Потратить пару месяцев до того, как система начнёт работать?

Чтобы посмотреть, как работает нормальная ОС. Арч ставится и настраивается за час по мануалу на оффсайте. Сказки про месяц выдумывают те, кто никогда арча в глаза не видел.