http://rulinux.net/ http://rulinux.net/ http://rulinux.net/rss_icon.png https://rulinux.net/message.php?newsid=38793&page=1#164610 https://rulinux.net/message.php?newsid=38793&page=1#164610 Mon, 28 Jan 2013 19:58:55 +0400 спс :)

]]> https://rulinux.net/message.php?newsid=38793&page=1#164608 https://rulinux.net/message.php?newsid=38793&page=1#164608 Mon, 28 Jan 2013 19:40:40 +0400 косплей на Иноуэ Орихиме(bleach orihime) из блича. Сама анимешка - го*но, серии после 40.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164607 https://rulinux.net/message.php?newsid=38793&page=1#164607 Mon, 28 Jan 2013 19:36:40 +0400 Слухай, а что за няшное создание у тебя на аватарке ?

И даже вроде не трансвестит, как у Сильви.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164606 https://rulinux.net/message.php?newsid=38793&page=1#164606 Mon, 28 Jan 2013 18:39:42 +0400 И совсем уж становится непонятно, зачем же бут-процессу глибци.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164605 https://rulinux.net/message.php?newsid=38793&page=1#164605 Mon, 28 Jan 2013 18:38:43 +0400 то то я слышал, так новую федору хвалят сильно. Надо будет попробовать...где-нибудь в сандбоксе...на дне туалета...

]]> https://rulinux.net/message.php?newsid=38793&page=1#164596 https://rulinux.net/message.php?newsid=38793&page=1#164596 Mon, 28 Jan 2013 17:33:00 +0400 > Миф: Systemd чрезмерно тяжелый и перегруженный.
> - Systemd вероятно является как раз обратным примером. Он модульный, предоставляет много функциональности, а требуемые зависимости включают в себя лишь Glibc, libcap и DBus.
Myth confirmed

]]> https://rulinux.net/message.php?newsid=38793&page=1#164595 https://rulinux.net/message.php?newsid=38793&page=1#164595 Mon, 28 Jan 2013 17:27:51 +0400 > создаётся 69 различных исполняемых файлов,
Ох бле, я обычно не смотрю, что у меня в /bin, но 69 файло на одну (!) прогу, это многовато. И после он говорит про "правильный" дизайн. Поедят ещё линуксоиды говна c этим идиотом.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164575 https://rulinux.net/message.php?newsid=38793&page=1#164575 Mon, 28 Jan 2013 08:02:13 +0400 o_0 Спойлер вообще работает ??!

]]> https://rulinux.net/message.php?newsid=38793&page=1#164574 https://rulinux.net/message.php?newsid=38793&page=1#164574 Mon, 28 Jan 2013 06:35:30 +0400 > p.s. Bod как обычно в своём репертуаре, захерачил на 1.5 страницы новость.


А я тут при чём, если в разметке вложенные теги не работают. Работает либо список, либо спойлер.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164573 https://rulinux.net/message.php?newsid=38793&page=1#164573 Mon, 28 Jan 2013 03:03:21 +0400 Не читал, но осуждаю.
p.s. Bod как обычно в своём репертуаре, захерачил на 1.5 страницы новость.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164572 https://rulinux.net/message.php?newsid=38793&page=1#164572 Sun, 27 Jan 2013 19:30:22 +0400 >> Миф: Systemd нестабилен и изобилует ошибками.
> - Этот тезис не подтверждается багтрекером системы Fedora.

Просто никто не знает как ЭТО должно работать, вот и не рейзят ничего.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164571 https://rulinux.net/message.php?newsid=38793&page=1#164571 Sun, 27 Jan 2013 19:10:49 +0400 На труполоре попался годный перевод:

СистемД монолитный.

- Не, у нас 69 бинарников в максимальной комплектации.

СистемД задрачивали на скорость.

- Неправда, мы просто всё сделали правильно, и поэтому оно быстрое.

Быстрая загрузка не нужна для серверов.

- Нет, нужна.

СистемД несовместим с шелл-скриптами.

- Да хоть на брейнфаке пишите, нам всё равно что у вас в бинарнике.

СистемД трудный в освоении.

- СиндромУтёнка.жпг.

СистемД не модульный.

- Неправда, конфигуряйте-компиляйте как хотите.

СистемД только для десктопов.

- Неправда, для всего, включая автомобили.

СистемД создали из-за того, что другие иниты придумали не мы.

- Неправда, мы тыкали палочкой в апстарт, и он оказался УГ.

СистемД — FDOшный проект.

- Не, мопед не их, мы просто разместили исходники.

СистемД не юникс.

- Бугага, у нас действительно нет кода из юникса™.

СистемД переусложнён.

- Ну типа того, но сейчас всё сложное и системд не сложнее.

СистемД раздут.

- Сначала определитесь, что значит «раздутие».

СистемД не умеет в BSD.

- BSD RIP

Но дебиан умеет в BSD.

- BSD RIP. И пусть используют уже существующие для bsd иниты.

Но ведь можно и было сделать портабельным.

- Идите лесом, линукс няшка, остальное УГ.

СистемД непортабелен без причины.

- См. выше, линукс — няшка.

У вас конфиги бинарные

- Нет, текстовые, даже без xml.

Много лишних фич.

- Для системы инициализации — да. Но у нас не система инициализации, у нас круче.

СистемД заставляет вас что-то делать.

- Не нравится, не ешь.

Нельзя запустить сислог.

- Можно, и логи будут более мягкие и шелковистые.

СистемД несовместим.

- В общем-то с протухшими инитскриптами совместим, а если не совместим, то это не бага, а документированная фича.

СистемД не скриптуется.

- Да вы охренели, у нас есть что-угодноctl и dbus-send.

СистемД требует использования левых конфигурялок.

- Неправда, у нас текстовые конфиги, всё просто и понятно.

СистемД нестабилен и забагован.

- А вы багрепорт отправили?

СистемД не отлаживаем.

- Отлаживаем, только быдлокодерские echo в скрипт больше не напихаешь.

Изменения ради изменений.

- Для всего есть причины, смотрите вики и доки.

СистемД — редхатовский проект.

- Неправда, у нас из 16 людей только 6 из редхата, остальные из рачлинукса, дебаина, интела и даже космонавтовские.

СистемД не позволяет держать /usr на отдельном разделе.

- Разрешает, в доках описано как, но если вы так делаете, вы всё равно писька.

СистемД не разрешает заменять компоненты.

- Не, пожалуйста, отрубайте компоненты и заменяйте их своим говном мамонта, мы так умеем.

СистемД непрозрачный из-за dbus.

- Дбас — это круто, модно и гораздо более прозрачно, чем рандомный интерфейс через сокеты.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164570 https://rulinux.net/message.php?newsid=38793&page=1#164570 Sun, 27 Jan 2013 19:02:43 +0400 Почитал. Моя позиция хейтера растолстела и укоренилась ещё более чем.

ЗЫЖ слежу за дебианом и тыкаю фряху.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164569 https://rulinux.net/message.php?newsid=38793&page=1#164569 Sun, 27 Jan 2013 18:32:16 +0400 Я любил простой и надежный lilo, любил настраивать иксы чрез xorg.conf, лучше понимал работу системы в целом. Но время и прогресс не стоят на месте...

Включат по дефолту системД, буду хавать и его, одним не нужным костылём больше или меньше, уже не важно.

]]> https://rulinux.net/message.php?newsid=38793&page=1#164568 https://rulinux.net/message.php?newsid=38793&page=1#164568 Sun, 27 Jan 2013 18:26:29 +0400 Неплохая статья по ссылке с труполора

http://amarao-san.livejournal.com/2574196.html

]]> https://rulinux.net/message.php?newsid=38793&page=1#164567 https://rulinux.net/message.php?newsid=38793&page=1#164567 Sun, 27 Jan 2013 18:06:07 +0400 Ну что же, частью своих утверждений он только подтвердил так называемые "мифы" (почему он их мифами тогда называет?). А части утверждений я, если честно, не понял. Например, что касается непортабельности systemd.. Что он понёс о специфичной для линукса функциональности и что он этим хотел сказать?!

]]> https://rulinux.net/message.php?newsid=38793&page=1#164566 https://rulinux.net/message.php?newsid=38793&page=1#164566 Sun, 27 Jan 2013 17:48:17 +0400 Леннарт Поттеринг (Lennart Poettering) опубликовал объёмную статью, в которой попытался опровергнуть 30 типичных мифов, связанных с системным менеджером systemd.

•   Миф: systemd является монолитом.
  
  - Леннарт считает что это неправда, поскольку при полной сборке всех компонентов systemd создаётся 69 различных исполняемых файлов, каждый из которых отвечает за решение своей задачи. При этом большая часть данных исполняемых файлов может использоваться обособленно, без привязки к systemd. Целью разбиения функциональности на отдельные исполняемые файлы произведено, например, для решения таких задач, как более полное разделение привилегий (каждый процесс снабжается привилегиями только для выполнения узких задач) и обеспечение параллельного выполнения операций в процессе загрузки.
  
  
•   Миф: главной целью systemd является скорость.
  
  - По мнению Леннарта, высокая скорость systemd - это всего лишь побочный результат правильного дизайна и архитектуры проекта. Разработчики специально не занимались выжиманием всей возможной производительности из кода. Более того в некоторых ситуациях разработчики предпочитают более читаемый код, чем немного более быстрый и запутанный.
  
  
•   Миф: скорость загрузки, предоставляемая systemd, не востребована на серверах.
  
  - Леннарт отмечает что многие системные администраторы напротив желают минимизации простоев (downtime) при выполнении обслуживания серверов. Кроме того, скорость старта востребована в облачных системах и на виртуальных машинах. Также критична скорость восстановления после сбоя систем высокой доступности.
  
  
•   Миф: systemd не совместим с shell-скриптами.
  
  - На самом деле он совместим, просто сами разработчики systemd не пользуются shell-скриптами в процессе загрузки, чтобы не терять преимущества systemd. Тем не менее, systemd позволяет запускать скрипты, написанные на любых языках программирования, как сервисы systemd.
  
  
•   Миф: освоить systemd сложно.
  
  - По мнению Леннарта это не так, поскольку это унифицированная платформа, язык файлов конфигурации прост и предоставляется типовой набор утилит. Тем не менее, Леннарт согласен с тем, что некоторое обучение работе с systemd все-таки требуется.
  
  
•   Миф: Systemd не модульный.
  
  - Это не так: в сборочном скрипте configure есть ряд ключей, позволяющих указать какие именно части systemd требуется собрать. Таким образом выбор предоставляемых возможностей осуществляется на этапе сборки.
  
  
•   Миф: Systemd только для десктопов.
  
  - Systemd охватывает примерно те же области использования, что и ядро Linux. Разработка Systemd одинаково позиционируется для десктопов, серверов и встраиваемых систем. Автопроизводители уже используют Systemd для автомобильных информационно-развлекательных платформ, Red Hat будет использовать Systemd в промышленном серверном дистрибутиве, проект GNOME задействует многие из интерфейсов Systemd для десктопа.
  
  
•   Миф: Systemd появился как результат синдрома NIH (Not Invented Here, создание собственного решения вместо использования уже существующих аналогов).
  
  - Изначально у разработчиков была идея использовать проект Upstart от фирмы Canonical, однако постепенно разработчики пришли к выводу, что у него есть ряд значительных недостатков в базовых основах дизайна, которые достаточно проблематично исправить. Наиболее крупным просчетом по мнению Леннарта является то, что upstart сам по себе не заботится о зависимостях сервисов и переносит заботу об этом аспекте на плечи администраторов и разработчиков.
  
  
•   Миф: systemd - проект FreeDesktop.org.
  
  - FreeDesktop.org используется в основном как инфраструктура хостинга.
  
  
•   Миф: systemd далёк от философии UNIX.
  
  - В systemd используется множество концепций UNIX, напрмер, идея "всё есть файл" реализована в доступе ко всем сервисам systemd осуществляется через файловую систему cgroupfs. Встроенная поддержка подключения нескольких рабочих мест к одному компьютеру выражается в поддержке multi-seat и возможности автоматической настройки подключаемого оборудования. Основу systemd составляет набор связанных через стандартные интерфейсы утилит, каждая из которых решает свою задачу.
  
  
•   Миф: Systemd сложно устроен.
  
  - Леннарт частично согласен с этим тезисом, однако отмечает, что это связано с тем что современные компьютеры стали сложными. Тем не менее, Леннарт считает, что systemd проще и содержит меньше избыточности и зависимостей, чем эквивалентные по возможностям решения.
  
  
•   Миф: Systemd чрезмерно тяжелый и перегруженный.
  
  - Systemd вероятно является как раз обратным примером. Он модульный, предоставляет много функциональности, а требуемые зависимости включают в себя лишь Glibc, libcap и DBus.
  
  
•   Миф: Systemd создан только для Linux и не может использоваться в BSD-системах.
  
  - По мнению Леннарта, основной причиной данной ситуации является то, что разработчики систем на основе BSD не заинтересованы в данной системе инициализации, так как исторически ядра BSD-систем развивались одновременно с пользовательским окружением вокруг них и данные системы имеют собственные системы инициализации, жестко привязанные к особенностям каждому BSD-проекту.
  
  
•   Миф: Systemd не сможет использоваться по умолчанию в Debian, так как он поддерживает только ядро Linux.
  
  - Леннерт отмечает, что работа по одновременному сопровождению unit-файлов systemd и классических init файлов является номинальной и незначительной по объему на фоне столь масштабной работы как внедрение в систему поддержки ядер, отличных от Linux.
  
  
•   Миф: Systemd можно портировать для других ядер, если мэйнтейнеры этих ядре этого пожелают.
  
  - Systemd слишком завязан на возможности и интерфейсы, доступные только в ядре Linux. В некоторых ядрах имеются аналоги подобных интерфейсов, некоторые возможности можно отключить, но все необходимые функции вряд-ли удастся обеспечить в ядрах, отличных от Linux. Среди активно используемых в Systemd возможностей: cgroups, fanotify, umount2(), /proc/self/mountinfo, /dev/swaps, udev, netlink, /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces, prctl(), ioctl, системный вызов mount(), selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input и т.п.
  
  
•   Миф: Systemd не является переносимым (Not Portable) без каких либо на то причин.
  
  - Это не так! Systemd просто использует специфичную для Linux функциональность чтобы реализовывать все что хотели сделать разработчики. У Linux столько возможностей, что остальные unix/posix системы попросту не предоставляют каких либо аналогов для многих из них, в то время как разработчики systemd желают дать в руки пользователей данные возможности.
  
  
•   Миф: Systemd использует конфигурационные файлы в бинарном формате.
  
  - В Systemd используются только простые и легко редактируемые вручную текстовые файлы конфигурации. Никакого XML и тем более бинарных форматов.
  
  
•   Миф: Systemd содержим избыточную функциональность.
  
  - Systemd изначально не ограничивался только системой инициализации и развивается как набор кирпичиков для построения ОС. Какие именно из возможности использовать решает пользователь, большая часть функций отключается на этапе сборки или в процессе работы.
  
  
•   Миф: Systemd заставляет кого-то что-то делать.
  
  - Программы - не мафия. Они не могут никого заставить что-либо делать против их воли. В Free Software каждый добровольно делает то, что считает нужным.
  
  
•   Миф: Systemd не позволяет использовать Syslog.
  
  - Это не так. Хотя у systemd есть свой метод ведения журналов, разработчики предприняли усилия чтобы сохранить полную совместимость с более традиционным syslog.
  
  
•   Миф: Systemd ни с чем не совместим.
  
  - Разработчики Systemd делают всё вохможное чтобы обеспечить наилучшую возможную совместимость с sysvinit. Большинство init-скриптов могут быть использованы с Systemd без необходимости внесения в них изменений. Имеющиеся несовместимости хорошо документированы.
  
  
•   Миф: К Systemd невозможно обращаться из скриптов из-за использования D-Bus.
  
  - Systemd предоставляет обширный набор утилит (systemctl, loginctl, timedatectl, hostnamectl, localectl) со всевозможными опциями, являющимися аналогами вызовов D-Bus, которые можно запускать из скриптов для автоматизации выполнения различных задач. Кроме того, нет никаких проблем с обращению к D-Bus из скриптов при помощи таких утилит как dbus-send и gdbus.
  
  
•   Миф: Systemd вынуждает использовать дополнительные конфигурационные утилиты вместо непосредственной правки файлов конфигурации.
  
  - Это не так. Конфигурационные утилиты предоставляют только дополнительную функциональность, такую как автодополнение имён директив конфигурации, но никто не заставляет обязательно их использовать. Пользователь может реализовать все действия через прямую правку файлов конфигурции с последующим ручным перезапуском связанных с ними процессов.
  
  
•   Миф: Systemd нестабилен и изобилует ошибками.
  
  - Этот тезис не подтверждается багтрекером системы Fedora.
  
  
•   Миф: Systemd трудно отлаживать.
  
  - В Systemd предусмотрен специальный отладочный интерфейс с поддержкой интерактивной отладки, отслеживания состояния, отключения компонентов при загрузке.
  
  
•   Миф: В Systemd изменения вносятся ради изменений.
  
  - Это не так, каждое вносимое в Systemd имеет техническое обоснование и разработчики по возможности стараются донести до общественности причины тех или иных изменений в wiki, блогах, документации и других источниках. Нарушающие совместимость изменения вносятся только в крайних случаях и явно документируются.
  
  
•   Миф: Systemd является проектом только компании Red Hat, которая использует трудоустроенных разработчиков для распространения своего мировоззрения.
  
  - Это не так, из 16 ведущих разработчиков Systemd только 6 работает в Red Hat, а остальные представляют такие проекты и компании как ArchLinux, Debian, Intel, Canonical, Mandriva, Pantheon.
  
  
•   Миф: Systemd не позволяет отделить /usr от корневой директории.
  
  - С самого начала systemd поддерживает опцию сборки "--with-rootprefix=", которая позволяет выделить необходимые для начальной стадии загрузки компоненты и установить их в корень или любою другую директорию. Хоть разработчики systemd и не считают загрузку без /usr хорошей идее, такая возможность поддерживается из коробки.
  
  
•   Миф: Systemd не позволяет заменять свои компоненты.
  
  - Это не так, большая часть возможностей Systemd может быть отключена и заменена на альтернативные реализации.
  
  
•   Миф: Использование D-Bus вместо сокетов делает Systemd непрозрачным.
  
  - D-Bus использует сокеты в качестве транспорта, но при этом предоставляет стандартизованный механизм сериализации сообщений, отправляемых через сокеты. Так как методы сериализации хорошо документированы и имеются штатные утилиты трассировки, то использование D-Bus наоборот делает систему более прозрачной, что нельзя сказать о многих Unix-демонах, которые использовали собственные протоколы для обмена данными.

]]>