OpenRC на Manjaro isos за хейтъри на Systemd

Днес, четейки моя RSS, разбрах интересна новина, че Блог Изгледът на репликатора, и то е, че в общността Манджаро са стартирани няколко ISO с особеността, че те не използват Systemd като init, друго OpenRC, системата за стартиране, използвана от Gentoo.

OpenRC

Не знам за вас, но темата 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 бита)
(md5sum: 80be54ecfb0360b2a8e544344f72113c)

manjaro-net-0.8.11-openrc-x86_64.iso (64 бита)
(md5sum: 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) Актуализираме системата

sudo pacman -Syu

3) Инсталираме предпочитаната от нас работна среда, пример използва LXDE

sudo pacman -S lxde

Информация за инсталиране на настолни среди може да бъде намерена в уики.

4) Инсталираме Session Manager:

sudo pacman -S lxdm -consolekit
Мениджърът на сесии също трябва да бъде зададен във файла /etc/conf.d/xdm и има повече информация тук y тук

5) Инсталираме някои пакети като аплета за мрежов мениджър

sudo pacman -S мрежов мениджър-аплет

6) Рестартираме системата

sudo рестартиране

Мисля, че от само себе си се разбира, че за това трябва да сме свързани с интернет чрез кабел. Ако използваме WiFi, можете да видите как да го направите в тази връзка.

ISO на Manajaro с OpenRC и OpenBox

В случая с Openbox ISO трябва да се вземат предвид някои неща:

  • Основната цел е да се направи по-лесен процес на инсталиране и позволяват настройвам по някакъв начин графика мрежата (използвайки зъл) и разделянето използване на GParted по желание.
  • Конфигурацията включва Openbox WM, LXTerminal, PCMan и NetSurf Web Browser (за търсене информация в уики o Google), и т.н.
  • Използвайте инсталатора на конзолата.

Връзки за изтегляне на ISO с OpenRC:

manjaro-openbox-openrc-2014-11-13-i686.iso (32 бита)
(md5sum: 9be7e75c75ab296f955a3396386c4764)

manjaro-openbox-openrc-2014-11-13-x86_64.iso (64 бита)
(md5sum: 07fd57df022118dfc9e2794a0ca3d26e)

Manjaro XFCE ISO с OpenRC

Само експериментално и за 64 бита има и ISO с XFCE:

manjaro-xfce-openrc-2014-11-14-x86_64.iso (64 бита)
(md5sum: e132f294f2ffd99c6cbc371d1e7a6d72)


Съдържанието на статията се придържа към нашите принципи на редакторска етика. За да съобщите за грешка, щракнете върху тук.

68 коментара, оставете своя

Оставете вашия коментар

Вашият имейл адрес няма да бъде публикуван.

*

*

  1. Отговорен за данните: Мигел Анхел Гатон
  2. Предназначение на данните: Контрол на СПАМ, управление на коментари.
  3. Легитимация: Вашето съгласие
  4. Съобщаване на данните: Данните няма да бъдат съобщени на трети страни, освен по законово задължение.
  5. Съхранение на данни: База данни, хоствана от Occentus Networks (ЕС)
  6. Права: По всяко време можете да ограничите, възстановите и изтриете информацията си.

  1.   един от някои каза той

    Прав сте, проблемът systemd започва да издава известен дъх, тъй като OpenRC е естественият наследник на текущия init. Ще видим къде свършва тази история.

  2.   Вилхелм каза той

    „Въпреки че за крайния потребител (или за мнозина) това не представлява нищо супер подходящо“

    Мисля, че същото не е от значение, тъй като като потребители не ни е засегнало работата на самата операционна система.

    Всъщност единственият голям (debian) е дал новина за „скандал“ по темата и въпреки че казват, че има и други причини, всички свързани systemd (и не трябва).

    Останалите големи дистрибуции, те не са създали проблем (или поне се проявяват с пики и факли), Fedora, Ubuntu и OpenSUSE.

    Оставя ми впечатление, че става дума за битка между програмисти, тъй като например opensuse 13.2 има добро приемане / критика и никой в ​​рецензиите не говори за systemd (дори ако е за установяване на дебат),

    Сега защо цялата суматоха от преминаването от systemd към OpenRC, ако в крайна сметка това не ги засяга.

    1.    Дерън каза той

      Лично от системното нещо ми става неприятно, имам несигурност, добър пост.

    2.    Юкитеру каза той

      Във Fedora имаше някакъв дебат за systemd, когато беше решено да се постави като init, имаше някои недоброжелатели на системата, главно защото те не се съгласиха да я използват като init по подразбиране, тъй като тя беше много свежа и имаше много недостатъци, но Повечето от основните разработчици са в основния екип за разработка и бяха свързани със systemd, така че заместването на Upstart с systemd беше знак за някакво налагане, в допълнение към проблема, че Upstart беше разработка на Ubuntu и има CLA доста намръщен, което в крайна сметка помогна на всички да приемат systemd без въпроси. По това време за OpenRC не можеше да става и дума, тъй като му липсваха много функции, които прави сега, включително паралелизация и поддръжка на cgroup.

  3.   анонимен каза той

    Страхотна новина! двоичен дистрибутор, който ще пусне 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 на потребителското пространство)

  4.   Ксиеп каза той

    Благодаря за информацията, elav!

    Споделям вашето мнение по отношение на systemd и също съм загрижен за дрейфа, който Linux предприе от появата на този нов init. Ако Wheezy остарее преди пристигането на вилицата на Debian, ще помисля да опитам Manjaro OpenRC, тъй като нямам свободно време да подготвя система Gentoo (оценявам това, но определено времето за компилиране на Gentoo е твърде обширна за моята лична ситуация).

    Поздрави!

  5.   Cristian каза той

    Elav, можете да опишете с по-малко от 10 думи за потребител, който не разбира твърде много „противоречието“, преди малко в блога има няколко статии, които са много технически и не завършват с обяснението на контекста за „непосветените“ ... някога Казаха ми, че независимо от техническото, обяснението трябва да бъде разбрано дори от баба ви, за да бъде добро.

    Всъщност във Fedora преди известно време проблемът ставаше непоносим до такава степен, че няколко потребители на настолни компютри мислеха да преминат към centos, за да заобиколят проблема

    1.    Луис каза той

      Подписвам се за тази молба.

      Systemd работи добре за мен. Какъв е проблемът, който причинява толкова много движение?

      Да кажем, че не знам.

    2.    дарио каза той

      systemd е програмата, която отговаря за стартирането на системата, но разработчиците на това решиха да я разширят и сега не само се занимава със стартирането, но и с неща като cron (програма за автоматично стартиране на програми), мрежата, системните регистрационни файлове, които между другото са двоични файлове, наред с други неща

      Мнозина не гледат благосклонно на такава рязка промяна, особено защото това е нов софтуер, следователно с много повече грешки, отколкото програми, които са работили през целия си живот, в допълнение към генерирането на зависимости при програмиране и например gnome е все по-често свързан с тази система. Правейки го по-малко преносим към други Unix платформи.

      Не знам дали другият ми коментар не е преминал модерацията, но той каза, че харесвам systemd, но те не трябва да позволяват да монополизира всички дистрибуции и да оставя алтернативи, както винаги е било правено в Linux за тези, които имат различни нужди.

    3.    дарио каза той

      Не успявам да кажа, че преди програмата, отговорна за стартирането на системата при стартиране, беше system v, която вървеше дълго време, докато не беше заменена в повечето дистрибуции от systemd xD.

    4.    елав каза той

      Към казаното от @daryo добавям следното (което е и моето мнение):

      Винаги съм харесвал философията на Unix, където една програма прави само едно нещо, но го прави добре. Когато Systemd иска да контролира всичко, което @daryo ви е казал, имам малко съмнение и какво би се случило, ако Systemd бъде някак компрометиран? Е, евентуално би могло да влачи със себе си всичко, което контролира.

      Към това добавям (и може би това е по-скоро по навик), че винаги съм харесвал, че системните ми дневници са чисти текстови файлове, но при Systemd всичко е двоично и команди като:

      cat log.txt

      o

      tailf log.txt

      Където бихме могли да използваме други опции като GREP за филтриране на определено съдържание, но Systemd използва имена команда journalctl.

      В допълнение към гореспоменатото, трябва да кажа, че тъй като RedHat е основният показател зад Systemd, получавам предупреждение, че не мога да се изключа. Може би греша, но това не изглежда добре .. И все се чудя каква е необходимостта да се контролира зареждането, cron, мрежата и колко услуга съществува? Какво имат предвид под това?

      1.    Александър каза той

        Благодарение на вашия коментар и това, което разследвах, мога да потвърдя вашите подозрения, че предупреждението е вярно, Бродър.
        Виждате ли, четох за 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 стелт

      2.    Юкитеру каза той

        Само за да допълни вашия хубав коментар @elav, systemd е NIH толкова висок, че сега твърди, че контролира следното:

        1. - Управление на интернет връзки с IPv4 и IPv6, използвайки systemd-networkd и systemd-nspawn.
        2. - Управление на DNS чрез вътрешен DNS кеш, разрешено от systemd.
        3. - Управление на многоадресни DNS във вътрешни мрежи, използвайки systemd-networkd.
        4. - Управление на TTY терминали в Linux, използвайки systemd-consoled. (Сбогом KMScon?)
        5.- Управление на сесии и привилегии чрез влизане.
        6. - Контрол на Coredump, използвайки двоични файлове и пропускане на директивите на ядрото.
        7. - Контрол на дневници, с помощта на двоични файлове и пропускане на директивите на ядрото.
        8. - Контрол на ACPI събития, използвайки logind. (Systemd-212 добави няколко главоболия към разработчиците на Nvidia с различни грешки, които направиха системата безполезна)
        9. - PPPoE поддръжка за networkd, работа, която все още е в ход.
        10. - Поддръжка на DHCP в клиент и сървър. (Какво правят с това? Нямам идея)
        11. - Поддръжка на системи с фабрично нулиране, което между другото е тясно свързано с BTRFS (Не се изненадвайте, ако BTRFS по-късно стане зависимост от systemd, добрият Lennart го обича)
        12 ..- Поддръжка за виртуализирани контейнери (предимно Xen и KVM)
        13. - Поддръжка за работа с устройство и инициализация (какво прави udev)
        14. - Работа с дискови системи за криптиране.
        15. - Зареждане на фърмуер и модули на ядрото.
        16. - Обработка на име на хост (създава уникален идентификатор за вашия компютър), помещения, време, NTP синхронизация, sysctl (променливи за управление на ядрото) и дори генератор на случайни числа (Много WTF това и поражда много подозрения)
        17. - Работа с временни файлови системи.

        Накратко дълъг списък, са нещата, които знам, че systemd прави, ако някой знае нещо повече от това да го каже :).

        PS: systemd вече не предлага поддръжка за LSB и SysV скриптове от systemd-214, така че не знам доколко истинска е тяхната „наследствена“ поддръжка сега или доколко те отговарят на стандартите. Казвам дали LSB все още е стандарт в Linux, или греша?

        1.    Алън Херера каза той

          Благодаря, че ми съобщихте, мислех да отида в BTRFS, но знаейки, че Леннарт го харесва, може би знаете, че той трябва да е ужасен и да шпионира NSA-IBM

    5.    анонимен каза той

      Има малко място за обобщение и обяснение толкова много ... това е гигантски троянски кон, който те дори не се опитват да покажат. Какво прави стартираща система, като поставя мрежови услуги, dhcp dns и дори аз мисля avahi ... в systemd? Силата на решението се губи, тъй като не можете да управлявате услугите
      които не са желани и че не идват при мен, които могат да бъдат деактивирани, не ги искам в системния пакет!
      В OpenRC той решава какви неща се стартират на всяко ниво на изпълнение, някои услуги имат зависимости от други услуги, но те са много малко и са изброени ... докато в systemd всичко прави каквото иска в момента Той се чувства така ... да спечели около 5 секунди при зареждане и да бъде бърз при изключване.
      Systemd е толкова сложен, че е невъзможно да се знае какво прави, трябва да се примирите с мисълта, че това е вашият господар и не ви прави нищо лошо.
      Systemd нарушава концепцията, че нещата трябва да бъдат лесни и разбираеми по отношение на демони или услуги и нива на изпълнение, никой, който използва systemd, не знае напълно какво се случва в техните услуги по всяко време.
      Systemd не позволява да се използва syslog-ng първоначално, те са направили журналд стъпка върху него и не му позволява да работи, тоест или използвате journald или naninga! Системният дневник е нещо фундаментално за сигурността и одита на случилото се и се случва с локалните и отдалечени връзки, но journald използва двоичен формат, който само jornalctl може да го види. неговия двоичен файл и когато го вижда повреден, той го изтрива веднъж и започва с нов, забравяйки всички дневници, които вече са съществували.
      Мога да продължа с часове, но най-лошият проблем е, че Lennart не дава топка на тези, които съобщават за тези грешки и доколкото чета, той не приема кръпки от никого.
      Мислех, че като влязат в systemd, те ще докладват за грешки и корекции, които systemd ще трябва да приеме ... но честно вярвам, че Lennart и RedHat имат друг план за останалите дистрибуции .... както казах преди, HORSE OF TROYA от RedHat.
      Честно казано за мен systemd не е поправим, идеята зад неговия дизайн е перверзно лоша, по-добре е да стартирате стартираща система от нулата, отколкото да се опитате да поправите този франкщайн.

      1.    елав каза той

        AMEN !! @anonymous ..

      2.    кунаги каза той

        Използвам systemd (Fedora) от около няколко години и стигнах до това:
        Проблемът мирише странно, тъй като повече неща добавят още деактивиране / пренасочване.
        Журналът, който директно насочих към rsyslog. Някои ваши двоични дневници вече са счупени.
        От dns използвам bind, ако го интегрират в systemd, ще продължа да го използвам по същия начин, дори ако трябва да модифицирам всичко.
        Използвам XFCE, така че ми спестява много от това, което gnome иска да интегрира.
        Това е като слон в магазин за порцелан.

      3.    Тито каза той

        Вярно; дори те не знаят как да го нарекат. Излизаме да актуализираме ежедневно, коригирайки грешки и други глупости. Това е тема, която доста ме ядосва; но не само поради факта, че SystemD е суверенна лайна; ако не как са го направили.
        Ясно е, че в света на Linux има няколко компании, които се опитват да контролират всичко; вижте Canonical, RedHat и Gnome, (дори самият Мигел де Icaza е напуснал Gnome).
        Ако използвам Linux, това е защото го контролирам и това е основата и философията на това; За да не знам какво прави, монтирам машини с W Server, който вече работи.
        Съжалявам за това, че Debian се поддаде. Всъщност се разглежда възможността за създаване на паралелна вилица без SystemD.
        Да се ​​надяваме, че нещата не отиват в повече; или се виждам как мигрирам всичките си машини към BSD.

      4.    Юкитеру каза той

        @ анонимен, коментар парче човече, не можеш да си по-прав.

        systemd е лудо нещо, което няма обяснение в много неща, истината предизвиква много подозрения във всичко, което прави и не позволява на други инструменти да го правят, истината е, че не знам как хората на Debian си позволяват това, но в крайна сметка те вече взеха това решение и за първи път от много години спрях да използвам Debian като основна операционна система и ще продължа да го правя, докато systemd излезе от Debian за по-прозрачна опция.

    6.    Тито каза той

      Накратко. SystemD е гадно.
      Той съхранява регистрационни файлове в двоичен формат, изпълнява се като родителски процес на всички останали, (Pid 1), с който ако някой се счупи, системата става невъзстановима; Това противоречи на всичко, за което се позовава Linux, тоест на обикновени текстови файлове (какво, по дяволите, са тези двоични файлове, обикновени текстови файлове! Както и целият живот на Бог.)
      Хайде, това са глупости. Изобщо нищо не ми харесва.
      Но благодарение на компании като Canonical, Gnome и Red Hat; ще го ядем с картофи.
      Че ако, докато има други възможности; Няма да го използвам нито на сървърите, които администрирам, нито на личните си машини.
      Това вече се превръща в клон на компанията Redmond.

      1.    сефирот каза той

        Не искам да защитавам никого, но добре си спомням, че каноничният беше напълно против systemd в полза на изскочителното. когато debian се поддаде на systemd, в крайна сметка се плъзна към ubuntu.

  6.   дарио каза той

    В допълнение, тези грешки могат да компрометират сигурността на системата и стабилността на сървър, например, затова тези, които се оплакват най-много от тези неща, са администраторът на sys.

  7.   Александър каза той

    А какво да кажем за Mageia, невероятно е, че KDE може да работи с 512 MB RAM, безупречно.
    http://mirror.cedia.org.ec/mageia/iso/cauldron/

  8.   Серджо Е. Дюран каза той

    няколко въпроса; Колко лесно е да управлявате услугите в OpenRC? и колко лесно е да се инсталира, като се използва по подразбиране в инсталация на Manjaro със systemd? това, което ми харесва в systemd е, че с простата команда systemctl enable (service) .service или systemctl disable (service) .service мога да управлявам услугите си лесно, АКО ме интересува да знам за OpenRC и особено ако мирише малко странно всичко това от systemd, между другото; Аз съм потребител на novell

    1.    Серджо Е. Дюран каза той

      Между другото; пише, че съм на Windows, защото използвам отмяна на потребителски агент

    2.    анонимен каза той

      OpenRC е много лесен за работа, давам ви пример с услугата за печат cupsd.

      За да го стартирате.
      # rc-service cupsd старт
      * Стартиране на cupsd .. [добре]

      За да го спре.
      # rc-service cupsd стоп
      * Спиране на cupsd ... [добре]

      За да го рестартирате.
      # rc-service cupsd рестартиране
      * Спиране на cupsd ... [добре]
      * Стартиране на cupsd .. [добре]

      За да го стартира в нивото на изпълнение по подразбиране.
      # rc-update добавяне на cupsd по подразбиране
      * услуга cupsd добавена към ниво на изпълнение по подразбиране [ок]

      За да го премахнете от нивото на изпълнение по подразбиране.
      # rc-update от cupsd по подразбиране
      * сервиз cupsd премахнат от ниво на изпълнение по подразбиране [ок]

      За да видите състоянието на всички услуги на всички нива на изпълнение.
      # rc -status -a

      За да видите състоянието на ниво на изпълнение, в този пример по подразбиране.
      # rc-status по подразбиране

      Тук в gentoo, OpenRC е системата за стартиране по подразбиране и ще остане такава завинаги, ние сме систематизирани в portage за самоубийствата, които за щастие са малко ...
      За да заменим journald, използваме syslog-ng и logrotate, тук в gentoo системният дневник излиза през виртуалната конзола vt12, която е control + alt + F12, или можете да го видите непрекъснато във всеки графичен терминал като root потребител с:

      # tailf / var / log / messages

      1.    Серджо Е. Дюран каза той

        И да го инсталирам на моя Manjaro?

      2.    Серджо Е. Дюран каза той

        Казвам; Няма да загубя всички файлове и красивия си XFCE само за преминаване към OpenRC 🙂

      3.    Серджо Е. Дюран каза той

        Готов; Инсталирах го с помощта на sudo pacman -S manjaro-openrc bluez-openrc (последният, защото имам Bluetooth)

      4.    Серджо Е. Дюран каза той

        Сега проблемът ми е, че XFCE4 диспечерът на захранването не работи с upower-pm-utils 🙁 и нямам типичните опции за спиране и хибернация

    3.    Юкитеру каза той

      OpenRC е много опростен, управлението на услугите е само за пример:

      Активиране на услуга: rc-update add cronie по подразбиране

      Стартиране на услуга: /etc/init.d/cronie start или rc-config start cronie

      Спрете услуга: /etc/init.d/cronie stop или rc-config stop cronie

      Просто и не е много сложно.

  9.   Юкитеру каза той

    @elav това, което предстои, е за дълги разстояния, вариращи от пясъчни бури, тролове от дъжд, насипни разклонения, разделяне на групите разработчици и мнозина, които се чудят дали мигрирането към BSD е по-добър вариант от засядането в systemd, защото да.

    Лично аз приветствам тази инициатива на Манджаро, това е опция за тези, които не искат да останат със systemd, нещо, което ми харесва, в момента съм в Gentoo и ми харесва, чувствам се комфортно със свободата, която ми дава, но сега Няколко пъти ми е минавало през ума, за да направя промяната на FreeBSD и може да направя скок през този месец, всичко зависи от времето ми и заповядането на някои неща да извърша миграцията успешно.

  10.   пампа каза той

    Аргументите срещу 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

    1.    Юкитеру каза той

      Нищо от това не опровергава реалността на systemd, Lennart е много добър в избягването на неща и отговорности, препоръчвам вместо просто да четете статии, да прочетете systemd кода или поне да прочетете списъка за разработка на systemd, ще разберете за неща, които опровергават казаното от тези три статии и се подкрепят по-скоро от недоброжелатели.

      1.    пампа каза той

        Аргументът му е да установи, че има знание, което опровергава това, което съм показал, но никога не представя доказателствата, така че не мога да се доверя на съществуването му.
        https://lists.debian.org/debian-ctte/2013/12/msg00234.html

      2.    Юкитеру каза той

        @pamp моят аргумент е малко по-голяма подкрепа, защото го обясних по-горе в коментар 25 на същия този запис и го изложих в много други записи относно systemd, в допълнение към излагането му в Debian irc и списъка на тази дистрибуция, също така моята покана е да създавате свои собствени мнения и за това просто трябва да прочетете малко списъка на разработката на systemd. Също така, за да събудя любопитството ви, ви давам тази връзка, в която те ясно казват, че systemd-214 вече не предлага поддръжка за SysV и LSB скриптове, с извинението за "почистване на кода".

        http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html

        Сега ми кажете: Къде е поддръжката за стандарта LSB, която се предполага, че е създадена, за да се създаде обща база за всички дистрибуции? Защото позволете ми да ви кажа нещо, нищо друго на първия си линк Lennart наблъсква, хвали се и пълни устата си, казвайки, че systemd поддържа използването на SysV и LSB скриптове, когато истината е, че поддръжката е отпаднала и заменена от генератор на init-файлове , който между другото има няколко грешки и в крайна сметка няма друг избор, освен да се направи пълен init-файл.

        Поздрави.

    2.    Тито каза той

      Мненията, това е като дупето, всички го имаме.
      Това, което казва този човек, може да му върви много добре, но не е моят случай. И мнението на човек, който пише в уеб портал, не е, че това е Божието слово. Това е вашето мнение, точка.
      Така че "опровергано", нищо.
      Хубавото, което ни остава, е, че можем да използваме каквото си поискаме; без да се опитваме да бъдем „талибани“ и да налагаме нашите критерии на другите.
      За мен SystemD е истинска глупост. И има хора, които го обичат. Е, добре дошли!
      Нито моето мнение е добро, нито това на тези, които не мислят като мен е глупост; те просто са различни.
      Това е, което ни отличава от другите операционни системи; можем да избираме.
      Нека не влизаме в безполезни битки, които не водят никъде.

      1.    анонимен каза той

        @Тито
        Не бихте могли да го кажете по-добре ... амин.
        Трябва да сте слепи, за да не осъзнаете извратеността, която систематизираните движат да покрият всичко, стъпвайки, покривайки и измествайки проекти, които работят перфектно, замествайки ги с версии, които никога не достигат или стават стабилни, дори няма съвместимост между ядра и повече от две задни версии на systemd.
        Изглежда, че Debian е получил земетресението и те са успели да се събудят, само се надявам да се наклонят към eudev и openrc, така че развитието на gentoo debian manjaro и някои други, които използват openrc, ще бъде унифицирано, което би го подобрило много за кратко време, спечелване на цялата общност.

      2.    Дах65 каза той

        Втори съм с вашите думи.

        Има хора, които цитират други хора (мненията, които ги интересуват, като цяло) и ги използват като доказателство.

        От своя страна нямам мнение по отношение на 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 замества, работят перфектно е преувеличено.

      3.    Юкитеру каза той

        Едно е мнение, а друго аргумент, със сигурност първото е много разнообразно, както казвате @Tito, но второто е нещо по-кратко и целенасочено, не е нещо, с което може да се манипулира толкова лесно, поне не в случая на безплатен софтуер, където имаме кода под ръка, за да го прегледаме.

        @pamp ни казва, че показаните аргументи са били опровергани от дълго време и като първи тест той ни запознава със мненията на Lennart (а не с аргументи). Но това, което този човек казва в коментарите си, е едно (цифрите 4 и 8 са просто за да умрат от смях), а друго е това, което прави в системния код. Отношение, което съм виждал многократно в Lennart, откакто той започна да разработва неща като Avahi и Pulseaudio, и което може просто да бъде потвърдено, като прочетете списъците за разработка и докладите за грешки на двата софтуера.

      4.    Юкитеру каза той

        @ Dah65 със сигурност много хора разполагат с доказателства, използвайки мненията на трети страни, лош навик за онези, които не могат сами да разследват проблемите, да имат свое и лично мнение и дори да създават валидни аргументи, с които да участват в конструктивна дискусия .

        В моя случай държа в крак с промените в systemd благодарение на списъка за разработка, въпреки че инструментът не ми харесва, тотално не ми харесва, но не спирам да чета за него на потребителско и техническо ниво и причината За това е много просто, ако трябва да присъствам на клиент, който използва споменатия init, знам какво трябва да направя и как да се занимавам с всяка ситуация.

        Сега относно това, което услугите се изпълняват без проблеми, това е грешка, има много SysV скриптове с проблеми и същото се случва в systemd, но поне когато съобщите за грешка в SysV, те са коригирани или можете да го направите по прост начин, както сте коментирали , в systemd, след като направите доклад за грешка, можете да намерите WONTFIX или CLOSED, благодарение на Lennart или Kay, в зависимост от случая и не преувеличавам, когато казвам това, пример тук:

        https://bugzilla.redhat.com/show_bug.cgi?id=753882

        Прочетете коментар 48, нямате загуба. 53-та на Клемент е друга, която няма загуба, особено заради своето архаично, но функционално решение на проблема, който Леннарт не иска да решава и който между другото беше докладван през 2011 г.

    3.    Марио каза той

      Онези "митове", които са ги установили? Някои са премахнати от галерията, тъй като „systemd не е преносим без причина“. Напълно вярно е, че не е преносим (и той признава, че казва, че е много персонализиран за Linux)
      Предполага се заблуди, като предположението, че BSD не се интересува (момчетата от BSD казват друго: „Джордан Хъбард - FreeBSD: Следващите 10 години (MeetBSD 2014)“), дори ако беше преносимо, те нямаше да го приемат и подобни неща (мит 13,14,15).

      Ако намерението на Poettering е да започнем да пренаписваме скриптове, изключително за вашата система (http://0pointer.de/blog/projects/systemd-for-admins-3.html) ще сгрешим. По принцип класическия скрипт за инициализация не се интересува къде отиваш. Направени са минимални промени, за да работят върху GNU, UNIX или BSD. Ами това беше до сега (освен ако не се използва OpenRC). Както и да е, мисля, че подобни неща ще доведат до разкол между Linux за настолни компютри и сървъри. Потребителите на Ubuntu и производни ще видят промените едва в края на следващата година.

      1.    анонимен каза той

        @ Dah65

        Е, тъй като казвате, че systemd не е персонифициран перверз, тогава ми кажете защо не пускат опциите Makefile, за да деактивират всички негови модули по време на компилация, така че тези от нас, които не обичат да имат тези "незадължителни модули", които стъпват други пакети, за да можем да ги компилираме и да създадем наши собствени версии на systemd capped!
        Знаете ли защо не го правят? Тъй като неговата форма на развитие се нарича принудително налагане и тъй като 95% от потребителите нямат NPI, те се възползват от подразбирането, ние го отказахме за всички вас.
        По този начин безплатният софтуер или софтуерът с отворен код или каквото и да искат да го нарекат не работи, сега ме кара да се смея, защото с новата вилица към Debian много хора излизат, за да мислят, че това е загуба на сила и аз все се питам трудно беше да се поставят допълнителни опции за компилация Makefile?
        Въпросът не дава повече, това е все едно да искате да смесите водата с масло, затова във всяка разработка ще има безкрайни разклонения, където има налагане на няколко за всички останали.

      2.    Юкитеру каза той

        @mario е точно това, което казвате. Джордан Хъбард също е осъзнал, че инициирането на BSD трябва да бъде актуализирано не само, за да се адаптира към новите технологии, но и да поддържа нови функции, които сега са възможни, но той заобикаля концепцията, която systemd сега има за това как трябва да се направи. нещата и го опростяват до философията, която винаги е преобладавала в UNIX, „Направете програма, която прави едно нещо и го прави добре“, и това в един инит е изключително важно, тъй като не говорим за още един демон, ние говорят за инициирането на операционна система, освен че е мярка за сигурност, в сравнение с това, което много специалисти вече започват да говорят за systemd, и това е очевидно, systemd прилича много на svchosts.exe от Windows, прави от init на услуги за мрежов контрол, наред с много други неща.

  11.   Луис каза той

    Момчета, наистина е страшно.

    Много сложно ли е да се премахне от ArchLinux ????

    Отивам да търся информация, но не смея да пипам такива неща, за да не се объркам и да загубя системата си.

  12.   Ману каза той

    От многото коментари, които прочетох, SYSTEMD е истински ТРОЙСКИ КОН ....
    Това означава да спаси кой може? Има малко информация на испански - за конфигурацията на работния плот във FreeBSD и подготовката на системата за използване.

  13.   Рафаел Мардохай каза той

    Лош systemd, нека бъде. xD

  14.   Уейко каза той

    Този омразен systemd няма да е вирусен ???? Arch ми се е получил чудесно ... ако е вярно, че покрива повече, не знам дали е добро или лошо! но може би вече има уязвимости за поемане на контрол или някакъв вирус, който унищожава системата поради това ... ако е стабилна и безопасна не виждам проблема ... така или иначе ще видя дали имам време и да проуча темата и да направя някои тестове с openrc

    1.    дарио каза той

      не толкова стабилна. и е много по-несигурен от система v. За потребител на настолни компютри като много от нас (аз) това също не представлява проблем, по-бързото зареждане работи добре и обикновено не чета дневниците, така че няма значение колко са ясни или дали е в двоичен формат.

      Имам теория, че Linux ще расте на настолни компютри (и правителства) и ще губи позиции на сървъри (вместо да приема OS като freebsd)

  15.   "Оскар" каза той

    В esdebian Wiki те публикуват как да инсталирате SysVinit на Debian Jessie. http://www.esdebian.org/wiki/sysvinit

  16.   анонимен каза той

    Четейки за сигурността, откривам, че от страна на Intel има дънни платки с чипсети, обикновено в северния мост те прилагат нещо, наречено AMR Intel Active Management Technology .... интересно, за щастие нямам Intel, но ще започна да го търся. AMD страна няма такова нещо.
    Те си представят комбинация от intel + AMR + systemd, не дай боже.
    https://en.wikipedia.org/wiki/Intel_AMT_versions
    Нищо чудно, че параноикът на Столман вика за безплатен биос.

    1.    Тито каза той

      Тихо; Intel се отказва от производството на дънни платки.
      http://www.infoworld.com/article/2612845/computer-hardware/intel-refocuses-and-exits-motherboard-business.html

  17.   Дах65 каза той

    На първо място, не използвам 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 системи американската NSA вече е сложила ноктите си. Ако тази новина беше вярна, не знам, защото не съм проследил темата. Но иронично е, че бягам от нещо, "защото Red Hat стои зад него и може би ...", за да вляза в нещо, което "може би NSA стои зад ...."

    В допълнение към използването на GNU / Linux, BSD, Windows или каквото искате да използваме, ние също можем да използваме нашата логика и способност да разсъждаваме

    1.    елав каза той

      На първо място, не използвам systemd, защото все още не е вграден в Kubuntu (аз съм с Netrunner 14, извлечен от Kubuntu 14.04).

      След като изяснихме това, трябва да бъдат посочени няколко неща:

      1- systemd се възприема от разработчици / пакети на много различни дистрибуции (Debian, openSUSE, Arch, Fedora ...), но сега се оказва, че читателите на този блог знаят повече от тях за предимствата и недостатъците на systemd.

      С други думи, читателите на този блог, бидейки само читатели, нямат способността да осъзнават дали нещо е добро или не, защото трябва да се ръководим от добрата преценка, знания и опит на опаковчиците и разработчиците.

      2- systemd е безплатен софтуер, чийто код може да бъде прочетен (и разбран) от тези, които имат време и познания (онези разработчици / пакети, за които говорих преди). Ако скриете задните врати, те ще бъдат открити. Колко от четците използват патентован фърмуер или драйвер, чийто код не сте прочели и не можете да прочетете? Мисля, че има повече смисъл да се страхуваш от това, отколкото не от systemd.

      Вярно е, че това е Свободен софтуер и ако се появи нещо странно, супер хората, за които сте говорили преди и на които трябва да се доверим, ще могат да го забележат и съобщят, а може би и не, защото може би, тъй като те са хора, ще бъдат изкушени да затворят в замяна От нещо.

      3- Всички работим с двоични пакети, защото когато изтеглям .deb от хранилищата, за да го инсталирам, не изтеглям обикновен текстов файл. Така че този аргумент е доста парадоксален.

      Когато изтегляте .deb, всичко, което правите, е да изтеглите компресиран файл, който можете да разархивирате и следователно да видите какво има вътре и какво е възможно, където е двоичният файл вътре. 😉

      6- За тези, които мислят да преминат към BSD, помня, че четох новини, че в някои BSD системи американската NSA вече е сложила ноктите си. Ако тази новина беше вярна, не знам, защото не съм проследил темата. Но иронично е, че бягам от нещо „защото Red Hat е отзад и може би ...“, за да вляза в нещо, което „може би NSA е зад ...“

      Не знам кои са потребителите, които ще избягат от Linux, за да отидат в BSD, но аз, например, не би трябвало да напускам Linux, трябва само да оставя дистрибуция, която поставя Systemd зад вас да или да.

      В допълнение към използването на GNU / Linux, BSD, Windows или каквото искате да използваме, ние също можем да използваме нашата логика и способност да разсъждаваме

      Накратко, тези от нас, които коментират, четат и използват GNU / Linux в този блог, не правят разсъждения. Това искаш да кажеш? Така или иначе ще ви кажа от моя личен опит и моите разсъждения (било то логично или не):

      Systemd е лайна, залепена на пръчка. Чел съм, че има и други Inits, които стартират много по-бързо и следователно не е необходимо да контролират DNS, RED, CRON и всичко останало, което Systemd иска да контролира. Може би за краен потребител, който се интересува само от включване на компютъра, отваряне на браузър и изпращане на имейли, няма значение дали използват Systemd или Systemx, но за тези от нас, които управляват сървъри, това е болка в задника. И аз ви задавам същия въпрос, който винаги задавам какво ще се случи, ако Systemd бъде компрометиран и отиде по дяволите? Останахме ли без ЧЕРВЕНО, без CRON, без DNS, без Init и всичко останало, което прави? Там го оставям за вас.

      И пазете се, казвам ви всичко това без ожесточение. Въпреки това, добре дошли в тези части.

      1.    Дах65 каза той

        Благодаря за добре дошли.

        Отговаряйки без опровержение, пояснявам, че нито разработвам systemd, нито получавам пари за популяризирането му. И че изобщо не ми засяга дали други хора го използват или не, това е тяхно решение.

        Но това, което виждам по този въпрос, понякога изглежда истерия и чета мнения на хора, които, без да са проучили кода или да са го използвали, го етикетират като боклук, налагане, предателство и не знам колко други неща. Това ми напомня на ситуация, която преживях преди няколко дни, когато човек, който призна, че никога не е инсталирал Windows или знае как да разделя твърд диск, започва да казва, че Linux е много труден ... без дори да го е изпробвал и също като Android на смартфона си.

        Сравнявали ли сте systemd със sysvinit, с upstart и с openrc? Чудесно, можете да вземете решение въз основа на собствения си опит. Това е най-доброто, защото вие също знаете, че дистрибуцията, която работи на един компютър, може да си струва на друг и затова тези от нас, които имат известен опит в GNU / Linux, казват, че най-добрият дистрибутор е този, с който потребителят се чувства комфортно. вкус.

        1- «С други думи, читателите на този блог, тъй като те са само читатели, нямат способността да осъзнаят дали нещо е добро или не, защото трябва да се ръководим от добрата преценка, знания и опит на опаковчиците и разработчиците»

        От доста време чета този блог (ще видите коментарите ми в стари новини), така че съм включен в пакета. И отговорът е, че не: четенето на този или който и да е блог не ми дава възможност (поне аз) да преценя доброто или лошото на софтуер, който не познавам. Мога да прочета какво казват другите и в този случай има позиции както за, така и против systemd; всъщност всеки път, когато темата се повдига в Phoronix, има много дебати, но дори и там спорените коментари са оскъдни. Имам предвид аргументи като "когато systemd извиква процес X, възниква безкраен цикъл, което прави системата неизползваема."

        И истината е, че използвайки дистрибуция или различна, вие се ръководите от преценката, знанията и опита на опаковчиците и разработчиците. Използването на която и да е операционна система или програма предполага отчасти разчитане на преценката и опита на другите; например с Linux приемате решението да използвате монолитно ядро, вместо да използвате микроядро като Hurd. Това решение беше на Линус Торвалдс и вие го приемате, като използвате неговото ядро.

        2- «Вярно е, това е Свободен софтуер и ако се появи нещо странно, супер хората, за които сте говорили преди и на които трябва да се доверим, ще могат да го забележат и съобщят, или може би не, защото може би, тъй като те са хора, те ще се изкуши да млъкне в замяна на нещо. "

        Е, подозрително, защо да се доверявам на Линус Торвалдс и Ричард Столман и на проекта GNU? Не съм разглеждал кода на вашите програми, така че може би те ме заблуждават.

        3 - «И аз ви задавам същия въпрос, който винаги задавам, какво ще се случи, ако Systemd бъде компрометиран и отиде по дяволите? Останахме ли без ЧЕРВЕНО, без CRON, без DNS, без Init и всичко останало, което прави? Ще го оставя там. »

        Ами ако OpenRC е компрометиран по някакъв начин? Или Upstart? Или ядрото? Случи ми се, след „нормална“ актуализация в Debian Testing, изчерпах grub, не можах да вляза в Debian или Windows и по това време незнанието ми означаваше, че имам само опцията за преинсталиране.

        4- «Накратко, тези от нас, които коментират, четат и използват GNU / Linux в този блог, не правят разсъждения. Това искаш да кажеш? "

        Не, нямам предвид това; Не възнамерявам да обобщавам от конкретна, конкретна ситуация до цялостното поведение на един или хиляда души. Но аз вярвам, че в случая на systemd се говори много пъти, без да се прави обективен и спокоен анализ; случи се и с Wayland-Mir, като се отправят много необосновани искове, както срещу Wayland, така и срещу Canonical.

        Също така повтарям, че чета и коментирам този блог (както и в други) и че използвам GNU / Linux.

        И аз също повтарям това, което казах преди: нека използваме мозъка си, анализираме това, което чуваме и четем, вземаме различни гледни точки, за да се опитаме да опровергаем както А, така и не-А, и ако е възможно, нека вземем собствения си опит, за да базираме заключенията си на факти . И тогава нека използваме всичко, което ни се струва правилно.

      2.    Уейко каза той

        хм ... ами това, че компрометирането е хипотеза, е като всичко .. въпросът ми вече е преминал? .. може би грешки не се намират във целия софтуер и те се коригират, ако има грешки в systemd, те го коригират и както всяка програма може да има грешките му .. проблемът не е в това, че може да се провали, а ако искате да прави или контролира какво прави, но не и в предположението, че може да се провали, всичко може да се провали за един момент ... аз не съм фен на systemd изобщо, това е само моето мнение.

        1.    елав каза той

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

      3.    Юкитеру каза той

        @waco със сигурност, ако получите грешки в софтуер, трябва да ги коригирате. Проблемът е, че systemd има много стари грешки (някои датиращи от 2010 г. и сериозни) и те все още не са коригирани днес, или просто омаловажени, или просто маркирани от Lennart като CLOSED или WONTFIX.

    2.    Уейко каза той

      вашият коментар е много успешен! Не можем всички да паднем до systemd, защото е модерно и е създадено като клеветническа кампания към това ... всяка промяна има отказ.

    3.    Юкитеру каза той

      Отговарям на вашите аргументи:

      1. - Сериозните и питащи потребители и разработчиците знаят предимствата и недостатъците на приемането на systemd във всяка разработка и работна среда, слабостите и силните страни на systemd не се променят поради една или друга перспектива.

      2. - Със сигурност systemd е безплатен софтуер и може да бъде одитиран. Проблемът не е в това, че има скрити задни врати, проблемът е, че прави неща, които даден инициатор не трябва да прави (мрежов контрол, dns, TTY конзоли и т.н.), че има много услуги, които се предполагат за другите, че прави нещата по съвсем различен начин от начина, по който се очаква да бъдат направени, което нарушава правилата на самото ядро ​​на Linux (coredump), че много от неговите разработчици се интересуват много малко от решаването на структурни проблеми, които systemd има (coredump и debug са сред най-сериозните, но все още нерешени).

      3. - Едно нещо е да изтеглите двоичен файл, който се оказва програма, чиято КОНФИГУРАЦИЯ и ЛОГИ са все още в обикновен текст, а друго е изтеглянето на двоичен файл, чиято КОНФИГУРАЦИЯ и друга информация се съхранява в двоичен файл и е достъпна само чрез конкретни инструменти, Тук нещата се променят. Двоичният дневник не предлага сигурност (ако наистина искате сигурност, шифровайте дяла с AES-256), той е просто черна кутия, от която не знаете нищо за случващото се и се поддава на много неща, например : Представете си, че имате троянски кон, който експлоатира системна уязвимост и чрез него получава пълен достъп до системата, включително услугата за регистрация и ескалация на привилегиите. Това не е ли сериозен проблем? Няма ли бинарните регистрационни файлове, обработвани директно от systemd, да се обърнат срещу вас, като са неприлични, без да стигнете до точката, че те вече са несъзнателно модифицирани? Има смисъл и разлика между програма и конфигурационен файл / дневници / сметища в двоичен файл.

      4. - Ядрото е софтуер, проектиран в този смисъл, той е проектиран от самото начало, за да контролира всичко на вашия компютър, а не инициализация. Init е посветен само на това да накарате вашата система да повдигне ядрото и да бъде използваема, защото това е първото нещо, което започва и последното нещо, което завършва. Ето защо се нарича init (инициализация), защото само стартира системата и не прави нищо друго, а причината за това е много проста, init трябва да бъде възможно най-стабилният и перфектен софтуер, за да се избегне това по някаква причина Това накрая нарушава цялата система, става въпрос за стабилност и сигурност. Xorg, е друг глас, той прави много неща, истина е, но нищо толкова рисковано, че да ви остави напълно неизползваема система, а също така нейната конфигурация все още се прави в обикновени текстови файлове.

      5. - Със сигурност дистрибуторите не са длъжни да предлагат свобода в широк смисъл и именно поради това се представя настоящата тирада. Но ние сме потребители и общността и много от нас просто не са съгласни с внедряването на тази система, ето защо правим така, че гласът ни да достигне, независимо дали те го слушат или не, това е въпрос на тези, които разработват distro и тяхното решение ще окаже влияние върху тези, които решат да използват дистрибуцията си или не, и това, очевидно може да доведе до провал на няколко дистрибуции в зависимост от това как вървят нещата и пример сега е Debian и неговата вилка Devuan.

      6. - Новините за BSD са заради случилото се в OpenSSH и в стека на OpenBSD IP, задна врата, която между другото засегна не само BSD, но и Linux (в случая на OpenSSH) и това беше поправено. Ситуацията се приписва на BSD, тъй като именно BSD (Theo de Raadt в OpenBSD) отговаря за разработването на този инструмент (OpenSSH) и ситуацията възниква, защото определени разработчици, които вече не са активни в проекта, са поставили задната врата. Ситуацията беше разрешена и бяха декларирани съответните мерки, които трябва да бъдат предприети, в случай че тази ситуация може да засегне тези, които са използвали софтуера. Сега: Може ли тази ситуация да възникне в systemd? Отговорът е прост и резултатът е катастрофален, тъй като systemd се справя с ескалацията на привилегиите, наред с много други неща, задната врата в systemd означава пълен достъп до системата, нещо, което не се е случило с бекдорите, споменати в BSD.

  18.   "Оскар" каза той

    Те връщат вилицата на Debian без systemd вече има уеб страница. Изглежда, че проектът върви и много сериозно. https://devuan.org/

  19.   Адитя Багга каза той

    Актуализирани ISO и някои нови качвания.
    https://forum.manjaro.org/index.php?board=50.0

  20.   Keos каза той

    Инсталаторът не е много ясен, не мога да следвам стъпките им, особено в частта от дяловете, не знам защо настояват за тези объркващи неща.

  21.   Мануел Р каза той

    Има нещо, което привлича вниманието ми относно netinstall с Openrc, някъде в инсталацията продължавам да виждам съобщението, че конфигурирате systemd, наистина ли ще бъдат освободени от systemd или неговото използване?

    1.    Keos каза той

      Здравейте Мануел, също забелязах същото по време на инсталацията, трябва да е въпрос на инсталатора, защото това, което няма съмнение е, че systemd не е инсталиран, вие потвърждавате в терминала по следния начин: pacman -Qs openrc

      поздрави

      1.    Мануел Р каза той

        Здравейте, keos, първо се извинявам, че не съм отговорил преди. Оценявам отговора ви, радвам се, че Манджаро предлага тази опция; веднага щом поддръжката на Ubuntu Precise приключи (или може би по-рано) ще я инсталирам. За разбирането.

  22.   Anonimo каза той

    Добър пост

    Ще изчакам в Manjaro със Systemd, докато версията на OpenRC узрее още малко, искам да изляза от systemd ... (изпотявам се)