Сьогодні, читаючи свій RSS, я дізнався цікаву новину, що Блог Погляд реплікатора, і це полягає в тому, що в Спільноті Манджаро було запущено кілька ISO з тією особливістю, що вони не використовують Systemd як init, ще OpenRC, система запуску, яку використовує Gentoo.
Я не знаю про вас, але тема Systemd вже дуже торкається моїх куль, і чим більше я читаю, тим більше я усвідомлюю, що хоча для кінцевого користувача (або для багатьох) вона не представляє нічого надзвичайно актуального, але принаймні для мене, мені не подобається цей шлях. Я вірю, що настане чорний сезон у світі GNU / Linux, де форки та невдоволення спалахнуть навіть у посушливих пустелях.
Але приступимо до справи. На форумі в Манджаро вони опублікували, як я вже говорив раніше, деякі ізо, які OpenRC використовує. А тим, хто боїться встановлювати ці версії, я залишаю відео, як це зробити.
Завантажте ISO за допомогою OpenRC
Перший ISO, який ми побачимо, - це версія NetInstall. Цей ISO має такі характеристики:
- На основі профілю Manjaro-Net (не має попередньо встановленого робочого середовища)
- Засноване на тестуванні.
- Тільки безкоштовні драйвери
- Використовуйте ядро Linux серії 3.14
- Не використовує Плімут
- Він був протестований у Virtualbox
Мову можна вибрати на початку, натиснувши клавішу F2. Після завершення процесу завантаження ми знайдемо підказку, де ми будемо використовувати для доступу:
- Користувач: root
- Пароль: манджаро
Щоб розпочати встановлення, як показано в попередньому відео, ми напишемо:
setup
Посилання для завантаження ISO
manjaro-net-0.8.11-openrc-i686.iso (32 біт)
(md5сум: 80be54ecfb0360b2a8e544344f72113c)
manjaro-net-0.8.11-openrc-x86_64.iso (64 біт)
(md5сум: ef205f70f3b3428545fdf1420db10b74)
Інструкції після встановлення
В Форум Манджаро Вони пропонують нам деякі дані для післяінсталяції:
Ми додаємо сховище openrc-eudev, дотримуючись цих інструкцій.
1) Ми додаємо наступне в кінці /etc/pacman.conf
[openrc-eudev] SigLevel = Необов’язковий сервер TrustAll = http://downloads.sourceforge.net/project/mefiles/Manjaro/$repo/$arch
Ми додаємо та імпортуємо ключі:
sudo pacman-key -r 518B147D sudo pacman-key --lsign-key 518B147D
2) Ми оновлюємо систему
Судо Пакман-Сю
3) Ми встановлюємо бажане середовище робочого столу, як показано в прикладі lxde
sudo pacman -S lxde
Інформацію про встановлення робочого середовища можна знайти в вики.
4) Ми встановлюємо Менеджер сеансів:
sudo pacman -S lxdm -consolekit
5) Ми встановлюємо деякі пакети, такі як аплет для мережевого менеджера
sudo pacman -S мережевий менеджер-аплет
6) Ми перезапускаємо систему
перезавантажити sudo
Думаю, само собою зрозуміло, що для цього нам потрібно бути підключеним до Інтернету за допомогою кабелю. Якщо ми використовуємо WiFi, ви можете побачити, як це зробити в посилання.
Манахаро ISO з OpenRC та OpenBox
У випадку з Openbox ISO слід врахувати деякі речі:
- Головна мета полягає в тому, щоб зробити процес встановлення простіший і дозволити configurar форма графік мережі (використовуючи злий) та розділення використання GParted за бажанням.
- Конфігурація включає Openbox WM, LXTerminal, PCMan та веб-браузер NetSurf (шукати інформація в вики o google), і т.п.
- Використовуйте програму встановлення консолі.
Посилання для завантаження ISO із OpenRC:
manjaro-openbox-openrc-2014-11-13-i686.iso (32 біт)
(md5сум: 9be7e75c75ab296f955a3396386c4764)
manjaro-openbox-openrc-2014-11-13-x86_64.iso (64 біт)
(md5сум: 07fd57df022118dfc9e2794a0ca3d26e)
Manjaro XFCE ISO з OpenRC
Тільки експериментально і для 64 біт існує також ISO із XFCE:
manjaro-xfce-openrc-2014-11-14-x86_64.iso (64 біт)
(md5сум: e132f294f2ffd99c6cbc371d1e7a6d72)
Ви маєте рацію, випуск systemd починає видавати певний нюх, оскільки OpenRC є природним наступником поточного init. Ми побачимо, чим закінчується ця історія.
"Хоча для кінцевого користувача (або для багатьох) це не представляє нічого надзвичайно важливого"
Я думаю, те саме, це не актуально, оскільки як користувачі це не вплинуло на нас в роботі самої ОС.
Насправді єдиний великий (debian) дав новину про "скандал" на цю тему, і хоча вони кажуть, що існують інші причини, всі пов'язані з цим systemd (і не повинні).
Інші великі дистрибутиви вони не створювали проблем (або, принаймні, проявлялися лопатами та факелами), Fedora, Ubuntu та OpenSUSE.
У мене складається враження, що це сутичка між програмістами, оскільки, наприклад, opensuse 13.2 добре сприймає / критикує, і ніхто в оглядах не говорить про systemd (навіть якщо це стосується дебатів),
Тепер навіщо стільки суєти, щоб перейти від systemd до OpenRC, якщо врешті це не впливає на них.
Особисто мені від системності стає неприємно, я маю невпевненість, добрий пост.
У Fedora були деякі суперечки щодо systemd, коли було вирішено поставити його як init, було кілька недоброзичливців до системи, головним чином тому, що вони не погодились використовувати її як init за замовчуванням, оскільки вона була дуже свіжою і мала багато недоліків, однак , Більшість основних розробників належать до основної команди розробників і були пов'язані з systemd, тому заміна Upstart на systemd була ознакою деякого нав'язування, крім того, що Upstart був розробкою Ubuntu і має CLA досить насуплений на, що врешті-решт допомогло всім прийняти systemd без сумнівів. Тоді про OpenRC не могло бути й мови, оскільки йому не вистачало багатьох функцій, які він має зараз, включаючи розпаралелювання та підтримку cgroup.
Відмінна новина! двійковий дистрибутив, який випустить openrc ... це схоже на знахідку.
Це шлях, яким повинен був пройти archlinux з самого початку, я пам’ятаю, коли мені довелося підтримати archlinux, перейшовши до systemd. Тепер у мене є можливість протестувати двійковий дистрибутив за допомогою openrc + eudev, який я саме використовую тут, у gentoo.
Дякую вам люди з Манджаро !!!
# eix -Ic openrc
[I] sys-apps / openrc (0.13.6@24/11/14): OpenRC управляє службами, запуском та вимкненням хоста
# eix -Ic eudev
[I] sys-fs / eudev (2.1.1@31/10/14): підтримка динамічного та постійного іменування пристроїв Linux (вона ж devfs користувацького простору)
Дякую за інформацію, elav!
Я поділяю вашу думку щодо systemd, і я також стурбований дрейфом, який зробив Linux після появи цієї нової ініціативи. Якщо Wheezy стане занадто старим до того, як прийде форк Debian, я подумаю про те, щоб спробувати Manjaro OpenRC, оскільки у мене немає вільного часу для підготовки системи Gentoo (я цінував це робити, але, безумовно, час компіляції Gentoo занадто обширна для моєї особистої ситуації).
Привіт!
Елав, ви можете описати менш ніж 10 слів для користувача, який не надто розуміє "суперечку". Нещодавно в блозі є кілька статей, які є дуже технічними, і вони не закінчують пояснення контексту для " непосвячений "... коли-небудь Вони говорили мені, що незалежно від технічного, пояснення повинно бути зрозуміле навіть вашій бабусі, щоб бути добрим.
Насправді у Fedora давно проблема ставала нестерпною, настільки, що кілька користувачів настільних комп'ютерів думали перейти на centos, щоб обійти проблему.
Я підписуюсь на цей запит.
Systemd добре працює для мене. Яка проблема викликає стільки руху?
Скажімо, я не знаю.
systemd - це програма, яка відповідає за запуск системи, але розробники цього рішення вирішили продовжити її, і тепер не тільки обробляє запуск, але і такі речі, як cron (програма для автоматичного запуску програм), мережа, системні журнали, які, до речі, є бінарні файли, серед іншого
Багато хто не сприймає такі різкі зміни, особливо тому, що це нове програмне забезпечення, тому набагато більше помилок, ніж програми, які працювали все їхнє життя, крім того, що вони створюють залежності при програмуванні та, наприклад, gnome, все частіше пов'язано з цією системою. Зробити його менш портативним для інших платформ Unix.
Я не знаю, чи мій інший коментар не пройшов модерацію, але він сказав, що мені подобається systemd, але вони не повинні дозволяти йому монополізувати всі дистрибутиви та залишати альтернативи, як це завжди робилося в Linux для тих, хто має різні потреби.
Мені потрібно сказати, що перед програмою, відповідальною за запуск системи під час завантаження, була система v, яка тривала довгий час, поки в більшості дистрибутивів її не замінив systemd xD.
До того, що каже @daryo, я додаю наступне (що також є моєю думкою):
Мені завжди подобалася філософія Unix, коли програма робить лише одне, але робить це добре. Коли Systemd хоче контролювати все, що сказав @daryo, я трохи сумніваюся, і що станеться, якщо Systemd якось скомпрометований? Ну, можливо, він перетягне все, що контролює, за собою.
До цього я додаю (і, можливо, це скоріше за звичкою), що мені завжди подобалося, що мої системні журнали - це чисто текстові файли, але з Systemd все є двійковим і такими командами, як:
cat log.txto
tailf log.txtДе ми могли б використовувати інші параметри, такі як GREP, для фільтрації певного вмісту, але Systemd використовує іменовану команду journalctl.
На додаток до вищезазначеного, я повинен сказати, що, будучи RedHat головним показником, що стоїть за Systemd, я отримую попередження, що я не можу вимкнути. Можливо, я помиляюся, але це не виглядає добре .. І я постійно дивуюсь, яка необхідність контролює завантаження, cron, мережу та скільки служби існує? Що вони мають на увазі під цим?
Завдяки вашому коментарю і тому, що я досліджував, я можу підтвердити ваші підозри, що це попередження є правильним, Бродер.
Ви побачите, що я читав про TCP Stealth, це німецька теза, де вони звинувачують Red Hat у сприянні промисловому шпигунству до систем прослуховування 5 очей:
Я вже писав про це, якщо у вас є необхідний талант, я знаю, що він у вас є, ви можете зробити власні висновки:
https://gnunet.org/sites/default/files/ma_kirsch_2014_0.pdf
http://heise.de/ct/artikel/GCHQ-NSA-El-programa-HACIENDA-2293098.html#TCP невидимість
Просто доповнюючи ваш приємний коментар @elav, systemd настільки високий, що зараз вимагає контролювати наступне:
1. - Управління підключеннями до Інтернету за допомогою IPv4 та IPv6, використовуючи systemd-networkd та systemd-nspawn.
2. - Управління DNS через внутрішній кеш DNS, вирішено в системі.
3. - Багатоадресне управління DNS у внутрішніх мережах за допомогою systemd-networkd.
4. - Управління терміналами TTY в Linux за допомогою консолі systemd. (До побачення KMScon?)
5. - Управління сесіями та привілеями за допомогою входу.
6. - Управління Coredump, використовуючи двійкові файли та пропускаючи директиви ядра.
7. - Керування журналами, використовуючи двійкові файли та пропускаючи директиви ядра.
8. - Керування подіями ACPI за допомогою входу. (Systemd-212 додав кілька головних болів розробникам Nvidia різними помилками, які зробили систему марною)
9. - Підтримка PPPoE для networkd - завдання, яке ще триває.
10. - Підтримка DHCP у клієнті та на сервері. (Що вони з цим роблять? Поняття не маю)
11. - Підтримка систем із скиданням заводських налаштувань, яка, до речі, тісно пов’язана з BTRFS (не дивуйтеся, якщо BTRFS згодом стане залежністю від systemd, хороший Леннарт це любить)
12 ..- Підтримка віртуалізованих контейнерів (переважно Xen та KVM)
13. - Підтримка управління пристроєм та ініціалізації (що робить udev)
14. - Обробка дискових систем шифрування.
15.- Завантаження прошивки та модулів ядра.
16. - Обробка імені хосту (воно створює унікальний ідентифікатор для вашого ПК), локального, часового, NTP-синхронізації, sysctl (змінні управління ядром) і навіть генератора випадкових чисел (дуже WTF це, і це викликає багато підозр)
17. - Обробка тимчасових файлових систем.
Коротше, довгий список, чи те, що я знаю, робить systemd, якщо хтось знає щось більше, ніж це говорить :)
PS: systemd більше не пропонує підтримку скриптів LSB та SysV, оскільки systemd-214, тому я не знаю, наскільки справжньою є їхня "застаріла" підтримка чи наскільки вони відповідають стандартам. Я кажу, що LSB все ще є стандартом у Linux, або я помиляюся?
Дякую, що повідомили, я думав піти на BTRFS, але знаючи, що він подобається Леннарту, ви можете знати, що він повинен бути жахливим і шпигувати за NSA-IBM
Мало місця для узагальнення та пояснення стільки ... це гігантський троянський кінь, якого вони навіть не намагаються демонструвати. Що робить система запуску, вкладаючи в systemd мережеві служби, dhcp dns і навіть я думаю, avahi ... Сила рішення втрачається через неможливість управління послугами
які не потрібні і що вони не приходять до мене, що можна деактивувати, я не хочу їх у пакеті systemd!
У OpenRC той, хто вирішує, що починати на кожному рівні запуску, деякі служби мають залежності від інших служб, але їх дуже мало і перераховані ... в той час як у systemd все робить все, що хоче, на даний момент. ... отримати приблизно 5 секунд під час завантаження та швидко зупинитися.
Systemd настільки складний, що неможливо знати, що він робить, ви мусите змиритися з думкою, що це ваш господар і не робить вам нічого поганого.
Systemd порушує концепцію того, що речі повинні бути легкими та зрозумілими з точки зору демонів чи служб та рівнів запуску, ніхто, хто використовує systemd, не знає повністю, що відбувається в їхніх послугах у будь-який час.
Systemd не дозволяє спочатку використовувати syslog-ng, вони змусили його наступити, і це не дає йому працювати, тобто ви використовуєте journald або naninga! Системний журнал є фундаментальним для безпеки та аудиту того, що відбувалося і відбувається з локальними та віддаленими з'єднаннями, але journald використовує двійковий формат, який може бачити лише jornalctl .... Дуже часто журналд пошкоджує "таємничо" свій двійковий файл і як він бачить, що воно пошкоджене, він видаляє його один раз і починає з нового, забувши всі журнали, які вже існували.
Я можу йти годинами, але найгірша проблема полягає в тому, що Леннарт не дає балу тим, хто повідомляє про ці помилки, і, наскільки я читав, він не приймає виправлення ні від кого.
Я думав, що потрапляючи в systemd, вони повідомлятимуть про помилки та виправлення, які systemd повинен буде прийняти ... але я щиро вірю, що Lennart та RedHat мають інший план щодо решти дистрибутивів .... як я вже говорив раніше , КІНЬ ТРОЇ від RedHat.
Чесно кажучи, для мене systemd не піддається виправленню, ідея його дизайну є погано поганою, краще запустити завантажувальну систему з нуля, ніж намагатися виправити цей франкштейн.
АМІН !! @anonymous ..
Я використовую systemd (Fedora) приблизно пару років і прийшов до цього:
Проблема дивно пахне, оскільки більше речей додає більше вимкнення / перенаправлення.
У мене журнал направлений безпосередньо до rsyslog. Деякі ваші двійкові журнали вже поламані.
З dns я використовую bind, якщо вони інтегрують його в systemd, я продовжую використовувати його так само, навіть якщо мені доведеться все змінити.
Я використовую XFCE, так що це економить мені багато того, що gnome хоче інтегрувати.
Це як слон у китайському магазині.
Правда; навіть вони не знають, як це назвати. Ми виходимо щодня оновлювати, виправляючи помилки та іншу лайно. Це тема, яка мене дуже злить; але не лише через те, що SystemD - це суверенне лайно; якщо не як вони це зробили.
Зрозуміло, що у світі Linux існує кілька компаній, які намагаються контролювати все; див. Canonical, RedHat і Gnome, (навіть сам Мігель де Ікаса покинув Gnome).
Якщо я використовую Linux, це через те, ким я керую, і це основа і філософія цього; Щоб не знати, що він робить, я монтую машини з уже запущеним W Server.
Мені шкода, що Debian піддався. Насправді розглядається можливість створення паралельної вилки без SystemD.
Будемо сподіватися, що справа не погіршиться; або я бачу, як переношу всі свої машини на BSD.
@ анонімний, коментар, чоловіче, ти не можеш бути правильнішим.
systemd - божевільна річ, яка не має пояснення у багатьох речах, правда викликає багато підозр у всьому, що вона робить, і не дозволяє іншим інструментам робити це, правда, я не знаю, як люди Debian дозволяють собі це ставити , але коротше вони вже прийняли це рішення, і вперше за багато років я перестав використовувати Debian як основну ОС і продовжуватиму робити це доти, доки systemd не вийде з Debian для більш прозорого варіанту.
Коротко. SystemD відстій.
Він зберігає журнали у двійковому форматі, він виконується як батьківський процес для всіх інших (Pid 1), за допомогою якого, якщо хтось зламається, система стає не підлягає відновленню; Це суперечить усьому, за що виступає Linux, тобто простим текстовим файлам (що, біса, що це бінарні файли ??, текстові файли! Як і все життя Бога).
Давай, це лайно. Мені взагалі нічого не подобається.
Але завдяки таким компаніям, як Canonical, Gnome та Red Hat; ми будемо їсти його з картоплею.
Це якщо, поки є інші варіанти; Я не буду використовувати його ні на серверах, якими я керую, ні на своїх персональних комп'ютерах.
Це вже стає філією компанії Redmond.
Я не хочу захищати когось, але я добре пам'ятаю, що канонічний був абсолютно проти systemd на користь вискочки. коли debian піддався systemd, він закінчився перетягуванням в ubuntu.
Крім того, ці помилки можуть порушити безпеку системи та стабільність сервера, наприклад, саме тому найбільше скаржаться на ці речі адміністратор sys.
А як щодо Mageia, неймовірно, що KDE може працювати на 512 Мб оперативної пам'яті, бездоганно.
http://mirror.cedia.org.ec/mageia/iso/cauldron/
кілька запитань; Наскільки легко керувати послугами в OpenRC? і наскільки легко встановити за допомогою його за замовчуванням при встановленні Manjaro з systemd? що мені подобається в systemd, це те, що за допомогою простої команди systemctl enable (service) .service або systemctl disable (service) .service я можу легко керувати своїми послугами, ЯКЩО мені цікаво знати про OpenRC і особливо якщо це пахне трохи дивно все це від systemd, до речі; Я користувач novell
До речі; Там написано, що я у Windows, бо використовую перевизначення агента користувача
З OpenRC дуже легко працювати, я наводжу приклад із послугою друку cupsd.
Щоб його розпочати.
# rc-сервіс cupd start
* Починаючи cupsd .. [ok]
Щоб зупинити це.
# rc-service cupsd зупинка
* Зупинка cupsd… [добре]
Щоб перезапустити його.
# rc-service cupsd перезапустити
* Зупинка cupsd… [добре]
* Починаючи cupsd .. [ok]
Щоб почати його на рівні запуску за замовчуванням.
# rc-update додати cupsd за замовчуванням
* службовий cupsd додано до рівня запуску за замовчуванням [ok]
Щоб видалити його із рівня запуску за замовчуванням.
# rc-update з cupsd за замовчуванням
* службовий cupsd вилучено із рівня запуску за замовчуванням [ok]
Щоб побачити стан усіх служб на всіх рівнях запуску.
# rc -status -a
Щоб побачити стан рівня запуску, у цьому прикладі за замовчуванням.
# rc-status за замовчуванням
Тут, у gentoo, OpenRC є системою запуску за замовчуванням і залишатиметься такою назавжди, ми систематизувались у порту для терористів-смертників, яких, на щастя, мало ...
Для заміни журналу ми використовуємо syslog-ng і logrotate, тут у gentoo системний журнал виходить через віртуальну консоль vt12 або control + alt + F12, або ви можете бачити його постійно в будь-якому графічному терміналі як кореневий користувач з:
# tailf / var / log / messages
А встановити його на моєму Манджаро?
Я кажу; Я не збираюся втрачати всі файли та свій прекрасний XFCE лише за перехід на OpenRC 🙂
Готовий; Я встановив його за допомогою sudo pacman -S manjaro-openrc bluez-openrc (останній, тому що у мене bluetooth)
Зараз моя проблема в тому, що менеджер живлення XFCE4 не працює з upower-pm-utils 🙁, і у мене немає типових опцій призупинення та сплячого режиму
OpenRC дуже простий, управління послугами - це шматочок, просто для прикладу:
Увімкнути службу: rc-update add cronie за замовчуванням
Запустіть службу: /etc/init.d/cronie start або rc-config start cronie
Зупиніть службу: /etc/init.d/cronie stop або rc-config stop cronie
Простий і не дуже складний.
@elav те, що чекає на довгий шлях, починаючи від піщаних бур, дощу тролів, насипних вилок, розколу групи розробників і багатьох, хто задається питанням, чи перехід на BSD є кращим варіантом, ніж застрягнення в systemd, тому що так.
Особисто я вітаю цю ініціативу Манджаро, це варіант для тих, хто не хоче залишатися з systemd, те, що мені подобається, на даний момент я перебуваю в Gentoo і мені це подобається, я відчуваю себе комфортно зі свободою, яку вона дає мені , але зараз мені кілька разів приходило в голову вносити зміни до FreeBSD, і я можу зробити стрибок цього місяця, все залежить від мого часу та замовлення певних речей, щоб успішно здійснити міграцію.
Аргументи проти systemd вже давно спростовуються. Прочитайте ще трохи, будь ласка.
http://0pointer.de/blog/projects/the-biggest-myths.html
http://diegocg.blogspot.mx/2014/02/la-sombras-de-sysyinit.html
http://diegocg.blogspot.mx/2014/02/por-que-kdbus.html
Ніщо з цього не спростовує реальність systemd, Леннарт дуже добре уникає речей і відповідальності, я рекомендую замість того, щоб просто читати статті, читати код systemd або принаймні читати список розробників systemd, ви дізнаєтесь про речі, які спростовують що говорять ці три статті, що сталося, і більше підтримують недоброзичливців systemd.
Його аргумент - встановити, що існують знання, які спростовують те, що я показав, але ніколи не представляє доказів, тому я не можу довіряти його існуванню.
https://lists.debian.org/debian-ctte/2013/12/msg00234.html
@pamp мій аргумент - це трохи більша підтримка, тому що я пояснив це вище в коментарі 25 цього самого запису, і я виклав це в багатьох інших записах стосовно systemd, окрім викладу в Debian irc та списку цього розподілу, також моє запрошення полягає в тому, що ви створюєте власні думки, і для цього вам просто потрібно прочитати невеликий список розробників systemd. Також для того, щоб викликати вашу цікавість, я даю вам це посилання, в якому чітко сказано, що systemd-214 більше не пропонує підтримку скриптів SysV та LSB, з виправданням "очищення коду".
http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
А тепер скажіть мені: Де підтримка стандарту LSB, який передбачається створити для того, щоб створити загальну базу для всіх дистрибутивів? Тому що дозвольте мені щось вам сказати, нічого іншого на своєму першому посиланні Леннарт пурхає, хвалиться і наповнює рот, говорячи, що systemd підтримує використання скриптів SysV та LSB, коли правда полягає в тому, що підтримка скидається і замінюється генератором файлів init , до речі, має кілька помилок, і врешті-решт, немає іншого варіанту, як створити повний файл-файл init.
Привіт.
Думки, це як дупа, у всіх нас одна.
Те, що говорить цей чоловік, може для нього дуже добре підійти, але це не мій випадок. І думка людини, яка пише на веб-порталі, полягає не в тому, що це слово Боже. Це ваша думка, крапка.
Так що "спростували", нічого.
Хороше, що нам залишилося, це те, що ми можемо використовувати все, що насправді хочемо; не намагаючись бути "талібами" і нав'язувати наші критерії іншим.
Для мене SystemD - справжнє лайно. І є люди, які це люблять. Ну, ласкаво просимо!
Ні моя думка не гарна, ні думка тих, хто не думає як я, - лайно; вони просто різні.
Це те, що відрізняє нас від інших операційних систем; ми можемо вибрати.
Не будемо вступати в марні бійки, які нікуди не ведуть.
@Тито
Ви не могли сказати краще ... амінь.
Потрібно бути сліпим, щоб не усвідомити всезахисність, яку систематизовані рушії охоплюють усе, наступаючи, охоплюючи та витісняючи проекти, які працюють ідеально, замінюючи їх версіями, які ніколи не досягають або стають стабільними, навіть якщо немає сумісності між ядрами і більше двох попередні версії systemd.
Здається, у Debian стався землетрус, і їм вдалося прокинутися, я просто сподіваюся, що вони схиляються до eudev та openrc, тому розвиток gentoo debian manjaro та деякі інші, що використовують openrc, будуть уніфіковані, що значно покращить його за короткий час час, вигравши всю громаду.
Я підтримую ваші слова.
Є люди, які цитують інших людей (думки, що їх цікавлять, загалом) і використовують їх як докази.
Зі свого боку, я не маю думки щодо systemd. Я не знаю, чи технічно це краще, ніж upstart або openrc, але те, що здається зрозумілим, це те, що можливість sysvinit виключається ВСІМ дистрибутивами, причому Debian є єдиним, хто все ще мав його в Wheezy завдяки своїй політиці. Але наступним стабільним Debian, Джессі, збирався стати Debian без sysvinit.
Очевидно, що етично це 100% безкоштовне програмне забезпечення; Що стосується його технічної частини, я ні вивчав код, ні порівнював його з його альтернативами, тому не маю аргументованої думки. Але навіть нинішня Ubuntu використовує частини systemd, хоча вони все ще мають вискочку, і я сумніваюся, що вони це зробили, оскільки Canonical "купується" Red Hat.
Systemd не є "злим", будь ласка, ми не боремося з Skynet (Термінатор) або HAL9000 ("космічна одісея 2001 року"), а також не є темною стороною Сили, яка прагне домінувати над джедаями. Також це не те, що, влаштувавшись у команду, він бере на себе все і змушує навіть продукти харчування в коморі зникати.
І що "це рухає проекти, які працюють бездоганно" (коментар 52), у мене були проблеми з домашньою мережею NFS на комп'ютерах, які отримують доступ до сервера, оскільки процес вимкнення клієнтського комп'ютера відключає мережу перед демонтажем системи NFS, і вимкнення замерзло б, єдиним рішенням було натиснути кнопку ввімкнення / вимкнення, щоб вимкнути його примусово (про помилку, про яку повідомляли різні користувачі); Мені довелося створити сценарій, який демонтує файли NFS для запуску перед вимкненням клієнтської машини. З іншого боку, сервер NFS-комп'ютера підключається через wifi, і час від часу зв’язок втрачається: я не знаю, чи проблема в мережевому менеджері, чи в dhcpd, чи де.
Я не кажу, що ці проблеми зникають із systemd; Я ігнорую це, оскільки я ним не користувався. Це лише зразок того, що сказати, що проекти, які замінюють systemd, працюють бездоганно, є перебільшенням.
Одна річ - це думка, а інша - аргумент, безумовно, перша дуже різноманітна, як ви говорите @Tito, але друга - це щось більш стисле та цілеспрямоване, це не те, чим можна так легко маніпулювати, принаймні, не в справа з вільним програмним забезпеченням, де у нас є код для його перегляду.
@pamp повідомляє нам, що наведені аргументи спростовувались протягом тривалого часу, і в якості першого тесту він ознайомив нас з думками Леннарта (а не аргументами). Але те, що цей хлопець говорить у своїх коментарях, - це одне (цифри 4 і 8 - це просто смерть від сміху), а інше - те, що він робить у системному коді. Позиція, яку я неодноразово бачив у Леннарті з тих пір, як я почав розробляти такі речі, як Avahi та Pulseaudio, і це можна просто підтвердити читанням списків розробників та звітів про помилки обох програм.
@ Dah65, безумовно, багато людей використовують докази, використовуючи думки третіх сторін, шкідлива звичка для тих, хто не може самостійно досліджувати питання, мати власну та особисту думку і навіть створювати вагомі аргументи, за допомогою яких можна брати участь у конструктивній дискусії.
У моєму випадку я в курсі змін у systemd завдяки списку розробників, хоча мені не подобається інструмент, він мені абсолютно не подобається, але я не перестаю читати про нього на рівні користувача та технічного рівня, а також причина Це дуже просто, якщо мені доводиться відвідувати клієнта, який використовує зазначений init, я знаю, що мені робити і як приймати участь у будь-якій ситуації.
Тепер про те, що служби працюють без проблем, що є помилкою, існує багато сценаріїв SysV з проблемами, і те саме відбувається в systemd, але принаймні, коли ви повідомляєте про помилку в SysV, вони виправляються, або ви можете зробити це за простий спосіб, як ви прокоментували, в systemd, після складання звіту про помилку, ви можете знайти WONTFIX або CLOSED, завдяки Lennart або Kay, залежно від обставин, і я не перебільшую, коли кажу це, зразок тут:
https://bugzilla.redhat.com/show_bug.cgi?id=753882
Прочитайте коментар 48, ви не втратите. Клемент 53 - ще одна, яка не втрачає, особливо за своє архаїчне, але функціональне вирішення проблеми, яку Леннарт не хоче вирішувати і про яку, до речі, повідомляли в 2011 році.
Ті "міфи", які їх встановили? Деякі видаляються з галереї, оскільки "systemd не переноситься без причини". Цілком вірно, що він не є портативним (і він визнає це, кажучи, що він дуже налаштований для Linux)
Він передбачає помилки, такі як припущення, що BSD не зацікавлений (хлопці з BSD говорять про протилежне: "Джордан Хаббард - FreeBSD: Наступні 10 років (MeetBSD 2014)"), навіть якщо він був портативним, вони не приймали його та інше так (міф 13,14,15).
Якщо намір Поеттерінга полягає в тому, щоб ми почали переписувати сценарії, ексклюзивні для вашої системи (http://0pointer.de/blog/projects/systemd-for-admins-3.html) ми підемо не так. В принципі, класичному скрипту init все одно, куди ви йдете. Мінімальні зміни вносяться для роботи на GNU, UNIX або BSD. Ну, це було дотепер (якщо не використовується OpenRC). У будь-якому випадку, я думаю, що подібні речі спричинять розкол між Linux для настільних ПК та серверів. Користувачі Ubuntu та деривативів побачать зміни лише наприкінці наступного року.
@ Dah65
Ну, оскільки ви говорите, що systemd не є персоніфікованим збоком, то скажіть мені, чому вони не вводять у опції Makefile, щоб вимкнути всі його модулі під час компіляції, щоб ті з нас, хто не любить мати ці "додаткові модулі "цей крок на інших пакетах, тому ми можемо їх компілювати та створювати власні версії systemd capped!
Чи знаєте ви, чому вони цього не роблять? Оскільки його форма розробки називається вимушеним нав'язуванням, і оскільки 95% користувачів не мають NPI, вони користуються перевагами за замовчуванням, ми відхилили його для всіх вас.
Ось як безкоштовне програмне забезпечення чи програмне забезпечення з відкритим кодом, або як би вони його не хотіли називати, не працює, тепер мене це сміє, тому що з новим форком для Debian багато людей думають, що це марне витрачання сил, і я продовжую дивуватися, наскільки важко це було поставити додаткові параметри компіляції Makefile?
Суб'єкт не дає більше, це все одно, що хотіти змішати воду з маслом, тому в кожній розробці будуть нескінченні виделки, де для всіх решти буде накладено кілька.
@mario - це саме те, що ви говорите. Джордан Хаббард також прийшов до тями, що ініціативу BSD потрібно оновлювати не тільки для адаптації до нових технологій, але і для підтримки нових можливостей, які зараз можливі, але він обходить концепцію, яку зараз має systemd, про те, як їх слід робити. і спрощують це до філософії, яка завжди панувала в UNIX, "Створіть програму, яка робить одне і робить це добре", і що в ініті надзвичайно важливо, оскільки ми не говоримо про ще одного демона, ми говорять про ініціювання операційної системи, окрім того, що це міра безпеки, порівняно з тим, що багато фахівців вже починають говорити про systemd, і це можна продемонструвати, systemd дуже схожий на svchosts.exe з Windows, робить з ініціювання служб для управління мережею серед іншого.
Хлопці, це справді страшно.
Це дуже складно видалити з ArchLinux ????
Я збираюся шукати інформацію, але я не наважуюся торкатися подібних речей, щоб не зіпсувати і не загубити свою систему.
🙂
https://abchk1234.wordpress.com/2014/06/03/using-openrc-on-arch-archbang-manjaro-linux/
З багатьох коментарів, які я прочитав, SYSTEMD - це справжній ТРОЯНСЬКИЙ КОНЬ….
Це означає, що можна економити, хто може? Іспанською мало інформації - про конфігурацію робочого столу у FreeBSD та підготовку системи до використання.
Бідна система, хай буде. xD
Ця система ненависті не буде вірусною ???? Арка чудово підійшла для мене ... якщо це правда, що вона охоплює більше, я не знаю, добре це чи погано! але, можливо, вже є вразливості, щоб взяти під свій контроль, або якийсь вірус, який руйнує систему через це ... якщо вона стабільна і безпечна, я не бачу проблеми ... у будь-якому випадку я подивлюсь, чи в мене буде час і вивчити предмет і зробити деякі тести з openrc - -
не такий стабільний. і це набагато небезпечніше, ніж система v. Для настільного користувача, як і багато хто з нас (я), це теж не представляє проблеми, швидше завантаження працює добре, і я зазвичай не читаю журнали, тому не має значення, наскільки вони чіткі або в двійковому форматі.
У мене є теорія, що Linux буде рости на робочих столах (і урядах) і втрачати позиції на серверах (замість того, щоб брати ОС на зразок freebsd)
На esdebian Wiki вони публікують, як встановити SysVinit на Debian Jessie. http://www.esdebian.org/wiki/sysvinit
Читаючи про безпеку, я виявляю, що з боку Intel є материнські плати з чіпсетами, як правило, на північному мості вони реалізують щось, що називається AMR Intel Active Management Technology .... цікаво, на щастя, у мене немає Intel, але я ' Почну шукати його на стороні AMD, такого немає.
Вони уявляють собі поєднання intel + AMR + systemd, не дай Бог.
https://en.wikipedia.org/wiki/Intel_AMT_versions
Не дивно, що параноїк Столлмана кричить про безкоштовний біос.
Тихо; Intel відмовляється від виробництва материнських плат.
http://www.infoworld.com/article/2612845/computer-hardware/intel-refocuses-and-exits-motherboard-business.html
Перш за все, я не використовую systemd, оскільки він ще не вбудований у Kubuntu (я з Netrunner 14, похідним від Kubuntu 14.04).
З’ясувавши це, слід вказати кілька речей:
1- systemd приймається розробниками / пакувальниками багатьох різних дистрибутивів (Debian, openSUSE, Arch, Fedora…), але тепер виявляється, що читачі цього блогу знають більше, ніж самі, про переваги та недоліки systemd.
2- systemd - це вільне програмне забезпечення, код якого можуть прочитати (і зрозуміти) ті, хто має час і знання (ті розробники / пакувальники, про які я вже говорив раніше). Якщо ви ховаєте задні двері, вони будуть виявлені. Скільки читачів використовують власну прошивку або драйвер, код яких ви не читали і не можете прочитати? Я думаю, що більше сенсу боятися цього, ніж не systemd.
3- Ми всі працюємо з двійковими пакетами, тому що коли я завантажую .deb із сховищ для його встановлення, я не завантажую звичайний текстовий файл. Тож цей аргумент є досить парадоксальним.
4- У GNU / Linux вже є програми, які роблять багато речей: одне і те ж ядро, яке все більше інтегрує більше драйверів, і навіть власну прошивку (краще закрити двері в закритій прошивці, ніж у програмі, чий код опублікований). Існує також Xorg, який не тільки обробляє графічний сервер, але й клавіатуру, мишу та інші речі; Ніхто не каже, що Xorg за це "зраджує" філософії UNIX, його хочуть звільнити, бо його вже наздогнали інші проекти.
5- "Linux - це вибір", звичайно, але це свобода вибору, чи хочу я прочитати код, змінити його, розповсюдити тощо. Не те, що дистрибутиви потрібні для вибору всіх варіантів (усі архітектури процесорів, усі середовища робочого столу, усі формати пакетів тощо)
6- Для тих, хто думає перейти на BSD, я пам’ятаю, як читав новини про те, що в деяких системах BSD американська АНБ вже поставила свої кігті. Якщо ця новина була правильною, я не знаю, оскільки я не стежив за темою. Але іронічно, що я тікаю від чогось, "тому що Red Hat позаду і, можливо, ...", щоб потрапити в щось, що "можливо, АНБ відстає ...."
На додаток до використання GNU / Linux, BSD, Windows або того, що ви хочете, щоб ми використовували, ми також можемо використовувати свою логіку та здатність міркувати
Іншими словами, читачі цього блогу, будучи лише читачами, не мають можливості зрозуміти, чи є щось добре чи ні, тому що ми повинні керуватися розумним судженням, знаннями та досвідом пакувальників та розробників.
Це правда, це Вільне програмне забезпечення, і якщо з’явиться щось дивне, суперлюди, про яких ви говорили раніше, і яким ми маємо довіряти, зможуть це помітити та оголосити, а може, й ні, бо, можливо, як люди, вони будуть спокушатися замовкнути у відповідь на щось.
Коли ви завантажуєте .deb, все, що ви робите, - це завантаження стисненого файлу, який ви можете розпакувати і, отже, побачити, що знаходиться всередині та можливо, де знаходиться двійковий файл всередині. 😉
Я не знаю, хто такі користувачі, які збираються втекти з Linux, щоб перейти на BSD, але, наприклад, мені не доведеться залишати Linux, мені потрібно буде лише залишити розподіл, який ставить Systemd позаду вас так чи так.
Коротше кажучи, ті з нас, хто коментує, читає та використовує GNU / Linux у цьому блозі, не міркує. Це те, що ти хочеш сказати? У будь-якому випадку я скажу вам з мого особистого досвіду та моїх міркувань (будь то логічним чи ні):
Systemd - це лайно, наклеєне на палицю. Я читав, що існують інші Inits, які запускаються набагато швидше, і тому їм не потрібно контролювати DNS, RED, CRON та все інше, чим Systemd хоче керувати. Можливо, для кінцевого користувача, котрий дбає лише про включення комп’ютера, відкриття браузера та надсилання електронних листів, неважливо, використовують вони Systemd чи Systemx, але для тих з нас, хто управляє серверами, це біль у дупі. І я задаю вам те саме питання, що й завжди, коли я запитую, що трапиться, якщо Systemd буде скомпрометовано і потрапить у пекло? Чи не залишилось у нас ні червоного, ні CRON, ні DNS, ні Init, ні всього іншого, що він робить? Там я залишаю це для вас.
І будьте обережні, я кажу вам все це без суперечок. Тим не менш, ласкаво просимо до цих частин.
Дякую за прийом.
Відповідаючи без звинувачень, я пояснюю, що я ні розробляю систему, ні отримую зарплату за її просування. І що це зовсім не впливає на мене, користуються ним інші люди чи ні, це їхнє рішення.
Але те, що я бачу з цього приводу, часом здається істерикою, і я читаю думки людей, які, не вивчивши код чи не використовуючи його, позначають його як сміття, нав'язування, зраду, і я не знаю, скільки інші речі. Це нагадує мені ситуацію, яку я пережив кілька днів тому, коли людина, яка визнала, що ніколи не встановлював Windows або знав, як розділити жорсткий диск, почала говорити, що Linux було дуже складно ... навіть не спробувавши це, і також має Android на своєму смартфоні.
Ви порівнювали systemd із sysvinit, з upstart та з openrc? Чудово, ви можете прийняти рішення на основі власного досвіду. Це найкраще, тому що ви також знаєте, що дистрибутив, який працює на одному комп'ютері, може бути вартим на іншому, і тому ті з нас, хто має певний досвід роботи в GNU / Linux, кажуть, що найкращим дистрибутивом є той, з яким користувач відчуває себе комфортно.
1- «Іншими словами, читачі цього блогу, оскільки вони лише читачі, не мають можливості зрозуміти, чи є щось добре чи ні, тому що ми повинні керуватися розумним судженням, знаннями та досвідом пакувальників та розробників. »
Я читаю цей блог вже досить давно (ви побачите мої коментарі в старих новинах), тому я включений у пакет. І відповідь - ні: читання цього чи будь-якого блогу не дає мені можливості (принаймні для мене) судити про хороші чи погані програми, яких я не знаю. Я можу прочитати, що говорять інші, і в цьому випадку є позиції як за, так і проти systemd; насправді, щоразу, коли тема піднімається у Фороніксі, багато суперечок, але навіть там аргументовані коментарі є мізерними. Я маю на увазі аргументи типу "коли при викликах systemd процес X виникає нескінченний цикл, що робить систему непридатною для використання".
І правда полягає в тому, що, використовуючи дистрибутив або інший, ви керуєтесь судженнями, знаннями та досвідом пакувальників та розробників. Використання будь-якої ОС чи програми передбачає частково покладання на судження та досвід інших; наприклад, у Linux ви приймаєте рішення використовувати монолітне ядро замість використання мікроядра, такого як Hurd. Це рішення було прийняте Лінусом Торвальдсом, і ви приймаєте його, використовуючи його суть.
2- «Це правда, це Вільне програмне забезпечення, і якщо з’явиться щось дивне, суперлюди, про яких ви говорили раніше і яким ми маємо довіряти, зможуть це помітити та оголосити, а може, й ні, бо, можливо, як вони є людьми, відчує спокусу замовкнути в обмін на щось ".
Ну, підозріло, навіщо довіряти Лінусу Торвальдсу та Річарду Столлману та проекту GNU? Я не дивився на код їхніх програм, тому, можливо, вони мене обманюють.
3 - «І я задаю вам те саме запитання, яке я завжди задаю, що станеться, якщо Systemd буде скомпрометований і потрапить до біса? Чи не залишилось у нас ні червоного, ні CRON, ні DNS, ні Init, ні всього іншого, що він робить? Я залишу його там ».
Що робити, якщо OpenRC якось порушено? Або Вискочка? Або ядро? Це трапилося зі мною, після "звичайного" оновлення в тестуванні Debian у мене закінчився grub, я не міг увійти в Debian або Windows, і на той момент моє незнання означало, що я мав можливість лише перевстановити.
4- «Коротше кажучи, ті з нас, хто коментує, читає та використовує GNU / Linux у цьому блозі, не міркує. Це те, що ти хочеш сказати? "
Ні, я не маю на увазі цього; Я не маю наміру робити узагальнення від конкретної, конкретної ситуації до сукупності поведінки одного або тисячі людей. Але я вірю, що у випадку з systemd про це говорять багато разів, не роблячи об'єктивного і спокійного аналізу; це також сталося з Wayland - Mir, було висунуто багато необгрунтованих претензій як до Wayland, так і до Canonical.
Крім того, я повторюю, що читаю та коментую цей блог (як і в інших), і що використовую GNU / Linux.
І я також повторюю те, що я говорив раніше: давайте використаємо наш мозок, проаналізуємо те, що ми чуємо і читаємо, візьмемо різні точки зору, щоб спробувати спростувати як A, так і не A, і, якщо можливо, давайте отримаємо власний досвід, щоб базувати наші висновки на фактах . А тоді давайте використаємо все, що нам здається правильним.
ммм .. ну що компрометація - це гіпотеза - це як усе .. моє питання вже пройшло? .. можливо помилки знайдені не у всьому програмному забезпеченні, і вони виправляються, якщо в системі є помилки, вони це виправляють і, як може мати будь-яка програма його помилки .. проблема не в тому, що він може зазнати невдачі, це якщо ви хочете, щоб він робив або контролював те, що робить, але не на припущенні, що він може зазнати невдачі, що-небудь може провалитися за мить ... Я не шанувальник systemd взагалі, це лише моя думка.
На комп'ютері користувача може статися помилка, і нічого не може трапитися, але на сервері все дуже і дуже сильно.
@waco, звичайно, якщо ви отримуєте помилки в програмному забезпеченні, вам слід їх виправити. Проблема полягає в тому, що у systemd є багато старих помилок (деякі датовані 2010 роком і серйозні), і вони все ще не виправлені сьогодні, або просто применшені, або просто позначені Lennart як ЗАКРИТИЙ або WONTFIX.
Ваш коментар дуже вдалий! Ми не можемо всі впасти на systemd, тому що це модно і було створено як наклепницьку кампанію до цього ... кожна зміна має відмову.
Я відповідаю на ваші аргументи:
1.- Серйозні та цікаві користувачі, а також розробники однаково знають переваги та недоліки прийняття systemd в будь-якому середовищі розробки та роботи, слабкі та сильні сторони systemd не змінюються через наявність тієї чи іншої точки зору.
2. - Безумовно, systemd - це вільне програмне забезпечення, яке можна перевірити. Проблема не в тому, що він має приховані задні двері, проблема полягає в тому, що він робить те, чого не повинен робити ініціатор (керування мережею, dns, консолі TTY тощо), що він має багато служб, призначених для інших, що він робить речі зовсім інакше, ніж те, як вони очікуються, що порушує правила самого ядра Linux (coredump), тому що багато його розробників дуже мало турбуються про вирішення структурних проблем, які має systemd (coredump та налагодження серед найсерйозніших, поки не вирішених).
3. - Одна справа - завантажити двійковий файл, який виявляється програмою, чиї КОНФІГУРАЦІЯ та ЛОГОСИ все ще є у звичайному тексті, а інша справа - завантажити двійковий файл, КОНФІГУРАЦІЯ та інша інформація яких зберігається у двійковому файлі та доступна лише через певні інструменти, Тут все змінюється. Бінарний журнал не пропонує безпеки (якщо ви дійсно хочете безпеки, зашифруйте розділ за допомогою AES-256), це просто чорний ящик, з якого ви нічого не знаєте про те, що відбувається, і він піддається багатьом речам, наприклад : Уявіть, що у вас є троян, який використовує системну вразливість і через неї отримує повний доступ до системи, включаючи послугу журналу та ескалацію привілеїв. Хіба це не серйозна проблема? Чи не бінарні журнали, якими обробляє безпосередньо systemd, не обернуться проти вас, ставши непристойними, не дійшовши до того, що вони вже несвідомо модифіковані? Існує суть і різниця між програмою та файлом конфігурації / журналами / дампами у двійковому файлі.
4. - Ядро - це програмне забезпечення, розроблене в цьому сенсі, воно розроблене з самого початку, щоб контролювати все на вашому ПК, а не ініціювати. Ініті присвячений лише тому, щоб ваша система підняла ядро і була придатною для використання, тому що це перше, що потрібно почати, і останнє, що закінчити. Ось чому він називається init (ініціалізація), оскільки він лише запускає систему і не робить нічого іншого, а причина цього дуже проста, init повинен бути найбільш стабільним і досконалим програмним забезпеченням, щоб уникнути цього з якихось причин Це закінчується руйнуванням всієї системи, мова йде про стабільність та безпеку. Xorg - це інший голос, він робить багато речей, правда, але нічого настільки ризикованого, щоб залишити вас абсолютно непридатною для використання системою, а також її конфігурація все ще виконується у простих текстових файлах.
5. - Безумовно, дистрибутиви не зобов'язані пропонувати свободу в широкому розумінні, і саме завдяки цьому представлена нинішня тирада. Але ми користувачі та спільнота, і багато хто з нас просто не згодні з впровадженням цієї системи, тому ми робимо свій голос доступним, слухають вони це чи ні, це справа тих, хто розробляє distro, і їхнє рішення вплине на тих, хто вирішить використовувати чи не використовувати їхній дистрибутив, і це, очевидно, може призвести до виходу з ладу кількох дистрибутивів залежно від того, як ідуть справи, і прикладом зараз є Debian та його вилка Devuan.
6. - Новини BSD - це те, що сталося в OpenSSH та в IP-стеці OpenBSD, задні двері, які, до речі, вплинули не тільки на BSD, але й на Linux (у випадку з OpenSSH), і це було виправлено. Ситуація приписується BSD, оскільки саме BSD (Тео де Раадт у OpenBSD) відповідає за розробку цього інструменту (OpenSSH), і ситуація виникла через те, що певні розробники, які більше не беруть участь у проекті, посадили задні двері . Ситуація була вирішена, а відповідні заходи, які слід вжити, були оголошені на випадок, якщо ця ситуація може вплинути на тих, хто використовував програмне забезпечення. Тепер: Чи може така ситуація трапитися в systemd? Відповідь проста, а результат катастрофічний, оскільки systemd, серед іншого, займається ескалацією привілеїв, бекдор у systemd означає повний доступ до системи, чого не сталося із бэкдорами, згаданими в BSD.
Вони повертають вилку Debian без того, що systemd вже має веб-сторінку. Здається, проект йде і дуже серйозно. https://devuan.org/
Оновлені ISO та деякі нові завантаження.
https://forum.manjaro.org/index.php?board=50.0
Інсталятор не дуже зрозумілий, я не можу слідувати їхнім крокам, особливо в тій частині розділів, я не знаю, чому вони наполягають на цих заплутаних речах.
Щось привертає мою увагу щодо netinstall з Openrc, десь в інсталяції я постійно бачу повідомлення про те, що ви налаштовуєте systemd, чи справді вони будуть вільні від systemd чи його використання?
Привіт Мануель, я теж спостерігаю те саме під час інсталяції, це має бути справа інсталятора, тому що, безсумнівно, є те, що systemd не встановлений, ти підтверджуєш у терміналі так: pacman -Qs openrc
привіт
Привіт, кеос, насамперед я перепрошую, що не відповів раніше. Я ціную вашу відповідь, я радий дізнатися, що Манджаро пропонує цей варіант; як тільки підтримка Ubuntu Precise закінчиться (а може і раніше), я її встановлю. Привітання.
Хороший пост
Я збираюся зачекати в Манджаро з Systemd, поки версія OpenRC дозріє трохи більше, я хочу вийти з systemd… (я потію)