Linux пользовательUlyssesJJ

Комментарии пользователя (137)

11.02.2025, 14:45
Mamma mia! Я звезда! :D

На некоторых устройствах нельзя даже поменять порядок загрузочных записей. В таком случае, единственным вариантом является установить Линукс и Виндовс в разные загрузочные разделы, и загрузочный раздел с Виндовс отключить. Предвосхищая вопросы, у меня четыре устройства с мультибутом.
На основном у меня один загрузочный раздел для Windows 10 и Linux ( в разное время стояли Debian 11, Debian 12, Ubuntu 22, Mint 21, ALT 11).
На другом легендарном устройстве, у меня, как упомянул choice для каждой ОС свой раздел. И да, именно на этом устройстве нельзя поменять порядок загрузочных записей.
На другом устройстве, у меня один EFI-раздел (исторически так сложилось), но там только Линуксы.
На четвертом устройстве у меня тоже только Линуксы, но у каждого свой раздел.

Я рекомендую делать для каждой ОС свой загрузочный раздел.
+ Не бояться затереть загрузчик других ОС во время дистрохопа.
+ Легко дистрохопить. Просто устанавливаете новую систему на место старой, будто там ничего и не стояло.
- Минусов я не вижу у данной схемы разметки. Потеря дискового пространства? 128 МиБ для раздела это более, чем за глаза. Можно даже 64 делать. Правда, некоторые особо одаренные установщики (наподобие того, который у Mint) этого не позволяют.
ссылка
09.02.2025, 20:27
Прикольная статья, мне понравилась. По-моему это первый обзор, в котором Deepin выступает как дистрибутив, а не как игрушка.
ссылка
29.01.2025, 15:31
Это да.
ссылка
28.01.2025, 16:05
Конечно, это только на 1% шутка. В UNIX гибкая система разграничения прав пользователей. И не давать некоторым пользователям полный доступ это даже очень правильно.
Недавно видео смотрел от одного сервисного центра. Маленький сын очистил жесткий диск родительского компьютера, на котором лежали все фотографии семейной жизни, чтобы установить игру про кораблики. Какую-то часть данных удалось восстановить, а часть, к сожалению, безвозвратно исчезла. На Linux такого бы не было. Достаточно создать сыну на компьютере свой аккаунт, чтобы он мог властвовать только в своем хомяке.
ссылка
28.01.2025, 15:38
Чтобы никуда не залезли, можно не говорить пароль от пользователя root
xD
Юмор
ссылка
28.01.2025, 15:02
Приятно, что на Пингвинусе появился такой талантливый писатель, который поднимает интересные темы. Читается на одном дыхании, написано легко и с юмором. Теперь я могу хоть опосредовано судить об опыте использования атомарных дистрибутивов.
Далее мои пять копеек и мое личное мнение.
Ну из минусов ostree очевидных, что это все очень сложно по сравнению с традиционными пакетами. Пакет rpm примитивен и создается простым spec-файлом, и примитивно устанавливается в директории согласно FHS (File Hierarchy Standard) (/usr/bin, /usr/share, /etc etc.). Директории, где оболочке следует искать исполняемые файлы заносятся в $PATH (/usr/bin, /usr/local/bin, /usr/libexec etc.). Кеш и индексирование пакетов пакетным менеджером это сложнее (особенно в случае rpm4), но это все равно под капотом, и ни пользователь, ни администратор с этим как правило не взаимодействуют. Простота традиционного подхода к установке пакетов потрясающая. Пользователь системы может самостоятельно собирать пакеты в систему, чтобы они работали также как установленные пакетным менеджером, без особых знаний и глубокого погружения в устройство системы. Системы с ostree таким свойством не обладают.
Во-вторых, все проблемы создает динамическая линковка. Пакет А зависит об пакетов Б и В, пакет В обновился с багой, пакет А из-за этого сломался, пакет А нужен для работы X.Org, X.org не стартанул, пользователь расстроен. Если бы пакеты в системе линковались статически, то зависимости не ломались во время обновления, держать несколько версий одного пакета было легко штатными версиями системы (симлинки), а даунгрейд в случае поломки стал бы примитивным делом. Пакет А собран статически с пакетами Б и В, пакет В обновился с багой, на пакет А это не влияет никак, потому что пакет А собран статически с рабочей версией пакета В, X.Org не упал, пользователь доволен.
Ну и в третих, я вот думал, а что будет если поставиь на ПК какой-нибудь Alma или другой ELTS (Extra Long Time Support) дистрибутив с KVM/QEMU только в качестве гипервизора, а для работы использовать гостевую ОС. Даже тот же Arch. Arch неудачно обновился, с помощью моментального снимка qcow2 откатился на предыдущеее состояние. Причем снимок полностью моментальный и полностью "полный" даже данные RAM можно в него занести. Потом можно свою систему с гипотетическим Arch полностью со всеми данными (даже в RAM) клонировать, поиздеваться над системой, и потом ее прибить без вреда для основного Arch. Современные мощные процессоры это без проблем тянут, и гостевая ОС не будет сильнее медленнее хостовой. Ну для такого использование данной конфигурации системы уже нужны специализированные сисадминские знания.
ссылка
21.01.2025, 21:58
Ничего не меняет.
ссылка
18.01.2025, 17:57
> Потому что в нём не ничего интересного
За это и его любим :)
ссылка
18.01.2025, 17:52
Докер и был придуман для решения проблемы dependency hell. Надеюсь, на этом обсуждение закончено.
ссылка
18.01.2025, 14:14
Почему? Это же Ubuntu без snap и с классическим рабочим столом. Звучит довольно неплохо. Для дистрибутива категории "как можно больше всего из коробки" и "поставил левой пяткой ноги и забыл" самое то.
ссылка
18.01.2025, 14:10
Это хорошо.
ссылка
18.01.2025, 13:58
Я тоже объяснил почему. Последний ваш абзац так же все объясняет. Все, что вы расписали удобно для разработчика. Но ложится тяжким бременем на мейнтейнеров и пользователей. Не очень удобно для одного скрипта на питоне поддерживать 100500 зависимостей, которые разработчик в него притащил, ведь это просто pip install. И конечному пользователю тоже не очень удобно держать все эти библиотеки и интерпретатор питона у себя в системе. Только разработчик у скрипта один, мейнтейнеров сто, пользователей десятки тысяч.
ссылка
17.01.2025, 21:57
Как раз наоборот. Потому что я в достаточной степени ознакомлен с языком и его инструментарием, я так считаю. Тем более, что из того, что я сказал неправда? С огромным рантаймом в лице компилятора - да! Своя экосистема (pip install) - да, даже система сборки у него своя - да.
ссылка
16.01.2025, 17:48
Python это показатель уровня программы и разработчиков. Он ужасен как язык для скриптования, потому что у него своя экосистема. И ужасен как язык для разработки, потому что интерпретируемый.
ссылка
16.01.2025, 17:46
Скриншот очень объемный. Интересно читать. Думаю поможет тем пользователям, которые хотят перейти на Fedora.
ссылка
14.01.2025, 16:08
Спасибо за статью!
Сам пробовал OpenSUSE на одном ноутбуке.
Потом решил поставить его на новый, но не завелось ! ;(
После граба просто кирпич без изображения и реакции на любый действия. Смена образа/версии/флешки не помогла.
Ну и я поставил на ноут Alma. Нужен был rpm, неважно какой. На старом ноуте Суся по-прежнему установлена, возвращаюсь к ней периодически.
ссылка
05.01.2025, 23:29
Красиво.
ссылка
02.01.2025, 15:56
Да, у Mint наиболее приятные темы. Тоже часто их тащу в свои десктопы на Xfce и на других дистрибутивах. Xfce по-моему единственная приемлемая среда рабочего стола. Остальные не стоят потраченного внимания и времени. ИМХО.
ссылка
30.12.2024, 16:24
"По сравнению со stable и unstable, testing имеет худшую скорость получения обновлений безопасности. Если речь идет о безопасности, не выбирайте testing."
https://wiki.debian.org/ru/DebianTesting

По прошествии какого-то времени тестируемый замораживают. Но он всё равно пока будет называться тестируемым. В этот период никакие новые пакеты из нестабильного дистрибутива в тестируемый перемещаться не могут, за исключением лишь тех, что содержат исправления ошибок, критических для выпуска (release-critical — RC).
https://www.debian.org/doc/manuals/debian-faq/choosing.ru.html#s3.1

В целом, по ссылке выше изложены за/против использования testing и sid.
ссылка
26.12.2024, 07:52
Вторя choice, по-моему замораживают только testing ветку. Sid обновляется всегда в "стабильном" режиме :D
Собственно и на сайте Debian пишут, если хотите новых пакетов, пользуйтесь Sid. И не пользуйтесь testing никогда и нигде.
ссылка
25.12.2024, 14:02
Выглядит потрясающе!
ссылка
22.12.2024, 16:28
Справиться можно со многими проблемами :) Главное, было бы желание :)
Кто-то ставит Ubuntu, кто-то Void. Мне больше из "андерграунд"-дистрибутивов нравится Alpine. Ну его все проблемы, которые я заметил, связаны с используемым инструментарием (busybox, musl-libc). С проблемами Void у меня не возникло желания справляться. Я сказал, — Фи! — и снес его. Мне не зашел он. Хотя дистрибутив можно порекомендовать. Мой друг по переписке пользуется только им и ничего другого не признает, например. Другой мой товарищ пользуется Manjaro и хейтит сильно Debian. Поэтому он никогда не упускает возможностм подколоть меня за то, что я пользуюсь Дебианчиком в качестве основной ОС. Каждому свое :)
ссылка
22.12.2024, 11:55
Void как и Alpine - дистрибутив не для всех. Для них действительно требуются и желания, и умения. Согласен.
ссылка
21.12.2024, 19:35
Без негатива. Нет специфичности проблем войда, есть проблемы специфичные для. Проблемы были с моим сетевым адаптером bcm4313, который работал только с одним определенным ядром, которое пришлось находить методом тыка и с помощью войдовских коллег. Так же у меня сломалось Xfce, когда я залпом установил все пакеты из goodies. Ну и проблему с наименованием пакетов в репозиториях я уже писал когда-то. Я не считаю, что Войд плохой дистрибутив. Он мне импонирует даже. Но он мне, что говорится, не зашел. ИМХО. Вы все делаете так :)
ссылка
21.12.2024, 12:58
По-моему у Void постоянно бардак в репозиториях. Я пытался им пользоваться, но приходилось слишком много времени тратить на специфичные Void-овские проблемы. По-моему у Alpine, хоть он и на musl, меньше косяков. За исключением отсутствия многих проприетарных драйверов (опять же из-за musl).
ссылка