Форум гитаристов

Что нужно осваивать в ОС, если нужен только браузер?

как настроить сеть. видюха какая?

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

есть нюансы. если дрова проприетарные и нужно 3Dускорение. это уже зависит от дистра, поставит он тебе сам дрова от производителя или свободный аналог (или всё надо делать самому) . в федоре не ставит на сколько помню, но ставится штатными средствами.

федора это полигон для тестирования редхата. Со стабильностью там не очень. Для дома лучше что-нибудь убунтообразное ставить.

федора это полигон для тестирования редхата. Со стабильностью там не очень. Для дома лучше что-нибудь убунтообразное ставить.

Не более чем слухи. Сижу на федоре уже какой год, сменил 3 ноута, 2 винта, 10 версий с fedora 19 до fedora 29 - все замечательно. Какие то мелкие баги в самой последней версии бывают, которые исправляются за полгода. Любителям стабильности имеет смысл сидеть на предпоследней. Про сервера уж молчу. Домашний сервер хост, медиасервер, торрент качалка, сервер видеонаблюдения - все под федорой уже годы.

Недостаток убунты в том, что:
- наличие PPA репозиториев. С одной стороны это удобство в большом выборе софта, но с другой стороны репозитории PPA имеют такой же доступ к разделу системы как и системные репозитории, т.е. права рута. А значит любой криворукий программист скажем метронома может своими шаловливыми ручками запросто пофигить твою систему в фарш совершенно невзначай.
- может я не понимаю как это сделано, но как мне показалось, убунта не отслеживает пакетную целостность системы (не считая установку зависимостей). В федоре есть история, каждая команда по установке пакета записывается со списком дополнительно установленных пакетов. Это можно откатить, нередко автоматом, если вдруг нужно, можно проверить насколько файлы в системе соответствуют оригинальным пакетам к которым они относятся, не повреждены ли, все ли на месте. В убунте ответа на вопрос: как удалить все пакеты, которые доставились с основным пакетом, я так и не нашел. Я так понял там просто большая помойка куда периодически ставится разное пока наконец не начнет потихоньку ломаться.
- многие вещи, особенно серверного толка, или того, что касается разработки ПО могут не работать сразу из коробки и после настройки их надо донастраивать. В отличие от той же федоры например, если знать как этим всем правильно пользоваться - поставил пакет, запустил и оно уже работает с общепринятыми в качестве стандарта настройками, оно уже пропишеться везде где надо, нужно будет минимум возни. В убунте нередко надо будет полотенце инструкций пройти.

Недостаток федоры (лично для меня) прежде всего в том, что убунта гораздо популярнее и не раз вы будете сталкиваться с тем, что инструкции по сборке какой нибудь программы из исходников даны именно для федоры (например криптовалютного кошелька какого нибудь), или собранный пакет только для убунты, а для федоры придется собирать руками, особенно актуально для тех, кто использует ОС для создания музыки например - всякие плагины, интересные проги бывает так, что собраны только для убунты. Или вот например есть у меня 3d принтер, есть Raspberry Pi, очень хотелось накатить Octoprint, но все инструкции под Дебиан (родственник убунты). Ладно, ок, можно поставить федору и приспособить инструкции под нее, но вот засада, в федоре еще не наладили работу с GPIO ( она и в Дебиане то наладом дышит).  Пришлось  терпеть Дебиан.

С учетом вышеизложенного вопрос выбора Федора или Убунта имхо больше вкуса - кому что важнее.

не надо под рутом работать.

RafaelRS, не про это писал. Но на самом деле он тоже не прав. Как .deb-пакеты, так и .rpm-пакеты могут иметь в своём составе скрипты способные "превратить в фарш" систему. Защитой от этого является контроль источников пакетов (например, реп) на основании авторитета, наблюдения фаз луны и т.п., а также контроль самих пакетов на основании подписи. Тоже не весть что и большинство этим не заморачивается (ССЗБ). Но никакого преимущества у like RHEL дистров перед like Debian дистрами из-за отсутствия PPA-реп нет и быть не может.

хм. тут не понял, где лучше...   

Linux for Scratch only, ессно 

... и добавил:

Ну и на закуску: Взломан сайт репозитория RPM Fusion. Ключевое: Администраторы сайта до сих пор никак не отреагировали на взлом

Да зачем скрипты. Достаточно, чтобы в пакете какой нибудь забывчивый девелопер случайно закинул свою кривую либу, которая заменит системную (вроде пакетный менеджер в Убунте это тоже не контролирует), и все, система в руинах.

Так это вообще не дело пакетного менеджера что-то контролировать. На это есть всякие активные IDS которые влезут и дадут понять пакетному менеджеру что всё прошло успешно, а пользователя тут же спросят: вот эта шляпа полезла менять ld-linux.so, согласен? Эта безопасность тяжело настраивается, больше подходит для прода и в конечном итого всё равно ничего не гарантирует, т.к. человеческий фактор как был, так и остаётся. Но лучше чем ничего.

Насчет взлома реп - одно дело, когда у тебя менее десятка реп, другое дело, когда их будет 20-50 на каждую мелкую прогу, да еще где не особо предъявляют требования к аккуратности ее ведения. Где вероятность возникновения косяка больше?

Вероятность больше там где у пользователя уши больше. Это не имеет отношения к плюсам/минусам дистра. Софт на like RHEL дистрах традиционно старый как [..] мамонта, на like Debian - наоборот, могут выкатить вообще неработающие пакеты. И это не значит что yum лучше apt, или наоборот. Ад зависимостей - и там, и там. Пользователь первого может как раз обвеситься репами, а второму может хватать только стандартного + ещё 1, без всяких ppa. Фломастеры.

Не согласен. Yum (теперь уже dnf) как раз это контролирует и не даст двум пакетам конфликтовать над одним файлом. Весьма удобно и позволяет легче сохранять целостность системы. По мне так это удобнее. Я как уже сказал например установил свою ОС в 2013 и обновлял множество раз с 19 версии до 29, чего только не ставил, удалял, все работает так же как если бы установил систему только вчера, т.е. нет эффекта набирающегося снежного кома после которого систему проще снести и установить заново.

В CentOS 7.5 по прежнему yum, поэтому про dnf знаю только что его надо специально ставить из epel. Dependency hell - это не про конфликты над одним файлом, а именно про зависимости. Проблема архитектурная и нерешаемая. У Вас в репе есть два пакета разных версий, один называется A, второй называется B и вместе они существовать не могут, а в системе есть пакет C которой зависит от B - приплыли. Говорим ставить пакет для A, он выносит B, тот по зависимости выносит C который уже в свою очередь выносит полсистемы. Ok, мы замораживаем B и принудительно ставим A. Никто никого не выносит, но мы имеем неработающий A, неработающий B, и отсюда неработающий C. Потому что надо было снести B, C, поставить A и что-нибудь D работающее с A (раз уж оно нам так надо).