LINUX.ORG.RU

systemd 215

 ,


1

3

4 июля был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала и управления сессиями пользователей. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые задачи по управлению системой — от настройки подсистемы VT (systemd-vconsole-setup) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

Большая часть изменений, вошедших в этот релиз, была направлена на поддержку т. н. stateless-систем, в которых все данные находятся на разделе /usr (монтируемом в режиме только для чтения), а корень (включая /etc) размещается на tmpfs и автоматически пересоздаётся при каждой загрузке системы. Этот функционал предполагается использовать в легковесных контейнерах, а также как средство «полного сброса» без переустановки ОС.

Изменения по поддержке stateless-систем:

  • Добавлен компонентsystemd-sysusers, способный автоматически добавлять и исправлять записи о служебных пользователях в /etc/passwd и /etc/group, основываясь на декларативных определениях из /usr/lib/sysusers.d. Наиболее важные определения уже поставляются в этом релизе.
    Этот функционал является частью работы по поддержке stateless-систем.
  • В секции [Unit] юнит-файлов добавлена директива ConditionNeedsUpdate=, инструктирующая systemd запускать юнит-файл только в том случае, если требуется обновление или перестроение директорий /etc или /var. Юнит-файлы, использующие эту директиву, вероятно, должны содержать также директиву Before=systemd-update-done.service.

    В поставку включён ряд unit-файлов, использующих этот функционал и реализующих перестроение:

    • базы данных аппаратного обеспечения udev (/etc/udev/hwdb.bin);
    • каталога сообщений journald (/var/lib/systemd/catalog/database);
    • кэша динамического компоновщика (/etc/ld.so.cache, т. е. ldconfig).
  • systemd-tmpfiles теперь поддерживает действия L+, b+, c+ и p+. Это варианты соответствующих действий без знака «+», принудительно удаляющие файл назначения.
  • В systemd-tmpfiles действия L, L+, C, C+ теперь допускают отсутствие поля «argument». В этом случае исходный файл берётся из директории /usr/share/factory/<полный путь к файлу назначения>. Разработчики ОС могут размещать в указанной директории стандартные файлы конфигурации, которые должны копироваться в системные директории при запуске системы с пустым корнем.

    В поставку включён конфигурационный файл для systemd-tmpfiles, пересоздающий наиболее важные файлы в /etc.

  • Добавлена команда systemctl preset-all, применяющая стандартные настройки включения/отключения ко всем установленным юнит-файлам.
    («presets» — функционал systemd, предназначенный для автоматического включения или отключения служб в стиле «как должно быть по умолчанию».)
    В случае запуска системы с пустым /etc, эквивалент этой команды выполняется автоматически, чтобы включить и активировать все «стандартные» службы.

    В поставку включён preset-файл, предназначенный для автоматического включения самых важных юнитов.

  • Файл /etc/os-release перемещён в /usr/lib/os-release, поскольку он является статическим и его изменение не предполагается. В директории /etc автоматически создаётся симлинк на новое местонахождение.

Прочие изменения:

  • systemd-networkd теперь включает в себя клиент DHCPv6, поддержку IPv6 Router Solicitation, а также сервер DHCPv4.
    Клиент DHCPv4 теперь поддерживает получение от сервера статических маршрутов.
    Секция DHCPv4 network-файлов была переименована в DHCP; совместимость со старым синтаксисом сохранена.
  • systemd-networkd теперь поддерживает управление виртуальными сетями VXLAN, TUN/TAP и dummy-интерфейсами.
  • systemd-networkd теперь поддерживает автоматическое назначение интерфейсам статических адресов из предварительно указанного диапазона. Этот функционал предназначен для управления большим числом однотипных соединений, таких, как veth-интерфейсы между хостом и контейнерами.
  • systemd-coredump теперь генерирует стектрейс всех потоков упавшей программы и пишет его в лог. Этот функционал реализован на библиотеке libdw из состава elf-utils.
  • systemd-coredump теперь может сохранять core-дампы на диск (/var/lib/systemd/coredump), а не в лог. По умолчанию включен режим сохранения на диск.
    Также был добавлен конфигурационный файл /etc/systemd/coredump.conf, позволяющий настраивать это поведение и некоторые другие параметры.
  • Утилита systemd-coredumpctl была переименована в coredumpctl, что означает её готовность к широкому использованию.
    Также была добавлена команда coredumpctl info, отображающая подробную информацию о зарегистрированных core-дампах.
  • journald теперь по умолчанию работает в режиме SplitMode=uid, т. е. файлы логов разделяются по UID источников сообщений.
  • Добавлена команда systemd is-system-running, позволяющая узнать общий статус запуска системы (starting, stopping, running, maintenance, degraded).
  • machined теперь экспортирует (позволяет узнать через D-Bus) версию ОС в запущенных контейнерах.
  • Команда systemctl -H (подключение к другой машине по сети) теперь позволяет заходить в контейнеры, запущенные на такой машине. Синтаксис для этого выглядит как root@host:container. Следует обратить внимание, что пользователь должен быть root, т. к. обращение к контейнеру — привилегированная операция.
  • В секции [Mount] unit-файлов добавлена директива SloppyOptions=, эквивалентная ключу -s программы mount(8). Эта директива включает режим нестрогой обработки несуществующих опций монтирования.
  • В секции [Install] юнит-файлов добавлена директива DefaultInstance=, указывающая, какую строку использовать как instance по умолчанию, если запрошено включение шаблонного юнита без явного указания instance.
  • В секции [Service] юнит-файлов добавлена директива RestartForceExitStatus=, позволяющая указать набор кодов возврата из главного процесса, при которых служба будет принудительно перезапущена (вне зависимости от значения директивы Restart=).
  • Добавлена обработка параметров ядра systemd.wants=, systemd.mask= и systemd.debug-shell. Их обработка реализована в новом генераторе systemd-debug-generator.
  • Добавлена пассивная цель cryptsetup-pre.target. Она предназначена для служб, которые должны запуститься до начала инициализации LUKS-устройств.
  • Добавлена страница документации file-hierarchy(7), содержащая рекомендации по организации иерархии файловой системы в дистрибутивах, использующих systemd. По сути, это является обновлённой версией FHS или hier(7). (Уже обсудили на ЛОРе.)
    Также была добавлена утилита systemd-path, позволяющая узнать точные (действующие) пути для некоторых пунктов из указанной документации.
  • Из поставки исключён unit-файл, периодически (по таймеру) пересоздающий кэш man-db. Он теперь будет поставляться в составе самого man-db (начиная со следующего релиза).
  • systemd.pc теперь экспортирует больше путей (в т. ч. libdir и некоторые директории файлов конфигурации второстепенных компонентов systemd).
  • В поставку включены макросы RPM для обработки файлов конфигурации systemd-sysusers, systemd-sysctl и systemd-binfmt (т. е. для их считывания и применения «на лету»).

Изменения, касающиеся udev:

  • Файлы устройств /dev/loop-control и /dev/btrfs-control теперь принадлежат служебной группе disk.
  • Функционал предсказуемых имён сетевых интерфейсов в udev теперь использует свойство dev_port (добавленное в Linux 3.15) вместо dev_id, чтобы различать несколько PCI-портов на одной PCI-функции.
  • Добавлена новая служебная группа input, которая теперь назначается всем файлам устройств ввода. Её предназначение во многом аналогично таковому для групп audio и video.

>>> Объявление о релизе

★★★★★

Проверено: fallout4all ()
Последнее исправление: fallout4all (всего исправлений: 4)

Ответ на: комментарий от tailgunner

Если речь о коммитах поцеринга...

тыц.

Вот и вся суть дракона. Из существенных коммитов - патч для фирмваря лаптопа от MSI i dmi-id.c (опять же для лаптопа) от 2006 и 2007 года.

Bот именно столько и именно таких патчей «Как и Леннарта уже в ядре»

anonymous
()
Ответ на: комментарий от anonymous

о блокировании чужой ветки речи не было, с чего ты так решил?

anonymous
()
Ответ на: комментарий от anonymous

отправился бы ты утчить матчасть. Тебе уже все расписали про Грега и Кая - нет ты опять свое. Или ты читать разучился?

anonymous
()
Ответ на: комментарий от anonymous

О, а вот и хвостострел за анонимусом стал ныкаться... Что, поглядел в логи коммитов и накрыло баттхёртом? Или ты так, заранее, по привычке?

anonymous
()
Ответ на: комментарий от anonymous

а вот и хвостострел за анонимусом стал ныкаться...

Бгг.

накрыло баттхёртом?

Фрейд снова смотрит на тебя с улыбкой.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Да весь этот тред, все >300 сообщений — фестиваль человеческой импульсной реактивной тяги.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

О боже...

В другом письме.

Возможно. Это что-то меняет?

«d» здесь нет. Это и есть трёхстрочник к удаву.

Нет, это 550 строк кода на C индемичного к systemd. Что мешало сделать это отдельной утилитой в духе xbacklight — догадайтесь сами.

Минималистичного аналога крона. Вас раздражает дублирование функционала? Идите ругайтесь на 99.9% существующих FOSS-проектов.

Минималистечнее crond? Вот хоть убей не вижу других причин кроме политики «все флаги в гости будут к нам».

ntp клиента

Внезапно, но ntpd предоставляет клиентскую функциональность в том числе. Ты не знал?

anonymous
()
Ответ на: комментарий от anonymous

А... Тебе 18. Тогда вопросов нет.

anonymous
()
Ответ на: комментарий от anonymous

Это что-то меняет?

Конечно.

Нет, это 550 строк кода на C индемичного к systemd. Что мешало сделать это отдельной утилитой в духе xbacklight — догадайтесь сами.

426, эквивалентные десяти строчкам на баше. Это и есть отдельная утилита.

Минималистечнее crond?

Да.

Вот хоть убей не вижу других причин кроме политики «все флаги в гости будут к нам».

Это твоя проблема.

Внезапно, но ntpd предоставляет клиентскую функциональность в том числе. Ты не знал?

ntpd — безусловно. Но в systemd-timesyncd нет ntp-сервера.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Конечно.

Да детка, это отличный аргумент. Раскрой тему, пожалуйста.

426, эквивалентные десяти строчкам на баше. Это и есть отдельная утилита.

Забавно, а в хидере написано, что part of systemd. Подобные вещи обычно делают отдельно, либо кладут в какой-нибудь util-linux. Однако, ребята из redhat опять решили завязать всё на себя.

Это твоя проблема.

См. пункт 1.

ntpd — безусловно. Но в systemd-timesyncd нет ntp-сервера.

К Л И Е Н Т С К У Ю.

Да-да, тебе не показалось. В моем первом посте я использовал термин `ntp-сервер' подразумевая ntpd, что не совсем корректно, но я думал, что ты меня понял. Нет, не понял. Так вот, timesync реализует эту самую клиентскую часть NTP (если быть ещё более точным — SNTP).

anonymous
()
Ответ на: комментарий от anonymous

Раскрой тему, пожалуйста.

В исходном сообщении 4.2, вот и всё.

Забавно, а в хидере написано, что part of systemd.

А вот в util-linux:misc-utils/namei.c написано, что «part of util-linux». Что ж ты на них желчь не изливаешь? (Вообще, ты, видимо, не знаешь, что эта фраза означает. Она означает, что к исходному коду применяется та же лицензия, что и ко всему проекту.)

Ну и да, связь между systemd и systemd-backlight примерно такая же, как и между kill и getopt. Но ты пришёл потроллить, поэтому я разъяснять не буду.

ntp-сервер

Ты удивишься, но я знаю, что systemd-timesyncd реализует только клиентскую часть протокола NTP. А в исходном сообщении написано — мол, в systemd есть свой ntp-сервер. Что опять же 4.2.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Ты не видишь разницы между небольшим набором утилит и «блоками для построения OS»? Серьезно?

anonymous
()
Ответ на: комментарий от intelfx

это 550 строк кода на C индемичного к systemd. Что мешало сделать это отдельной утилитой в духе xbacklight — догадайтесь сами.

426, эквивалентные десяти строчкам на баше

Эпик вин, да.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

На самом деле, там все несколько сложнее. Есть небольшая эвристика, которая позволяет определить, что два raw backlight устройства одно и то же. Но ведь это действительно стоило бы вынести в отдельную утилиту, чтобы делать не `echo 75 | sudo tee /sys/class/intel_backlight/brightness', а `brightness -s max intel_backlight'. Надо бы написать на выходных :D

anonymous
()
Ответ на: комментарий от anonymous

Надо бы написать на выходных

Только добавь, пожалуйста, опцию `--persistent', что бы поигравшись с `-s max', `-s 50%', `-s 10%', можно было бы просто сохранить то, что подходит, с минимумом усилий и неоднозначностей

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Ну да, надо сделать возможность дампить чочо, и дергать на старте `backlight -r all' на старте системы.

anonymous
()
Ответ на: комментарий от anonymous

Разница есть, но непринципиальная.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Эпик вин, да.

Вполне.

И в чем жде он заключается?

Ни одной строчки на баше.

Шеллофобия - это болезнь. Желаю тебе выздороветь, а то ведь вырастешь большой - начнешь переписывать procfs и sysfs.

tailgunner ★★★★★
()
Ответ на: комментарий от intelfx

При том, что в них можно писать через `sh'. И многие вещи делаются легко и элегантно именно скриптами из трех строк на sh.

anonymous
()
Ответ на: комментарий от anonymous

А можно и не через sh. // сабж тоже делает именно так

Я не утверждаю, что шелл не нужен. Но если можно без него — значит, стоит так сделать.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Шеллофобия - это болезнь. Желаю тебе выздороветь, а то ведь вырастешь большой - начнешь переписывать procfs и sysfs.

procfs и sysfs - это хорошие, довольно высокоуровневые API. Шелл это хорошая прослойка, интерфейс управления системой, в том числе этим API. Однако, в качестве интерфейса управления сам по себе шелл низкоуровен, без предоствления системой стандартного API слишком видны детали реализации и полная разнородность в управлении разных систем, хоть они и «Linux».

Напримир, делаем `iptables <...>', `iptables-save'. Куда записать вывод? Неопределенность. Далее, `iptables-restore'. Откуда его вызывать, с каким параметром дампа? А ведь можно из кучи разных мест. Неопределенность. На каждом дистрибутиве, на каждом инстансе одного дистрибутива по воле админа - везде нюансы в управлении базовыми вещами. Хотя, казалось бы, достаточно таких понятий, как `управление_запуском_сервиса iptables' и `управление_параметрами_сервиса iptables'. Это называется абстракция.

Deleted
()
Ответ на: комментарий от intelfx

Эээ... Нет. Ты неправильно понимаешь ситуацию. Если можно сделать на sh — надо сделать на sh. Потому что это в 95% случаев проще.

anonymous
()
Ответ на: комментарий от Deleted

procfs и sysfs - это хорошие, довольно высокоуровневые API. Шелл это хорошая прослойка, интерфейс управления системой, в том числе этим API.

Я не понял, к чему ты ведешь. Итак, переписывание 10 строк на shell в 426 строк на Си - это вин или фейл? Обоснуй свой ответ.

Однако, в качестве интерфейса управления сам по себе шелл низкоуровен, без предоствления системой стандартного API слишком видны детали реализации и полная разнородность в управлении разных систем, хоть они и «Linux».

Снова ничего не понятно. Почему ты всё время называешь shell «интерфейсом»? Shell - это язык программирования. «Интерфейс» в обсуждаемом случае - это sysfs. И этот интерфейс спроектирован так, чтобы его можно было удобно использовать из shell.

[...] Это называется абстракция.

Я могу только сказать, что ты изъясняешься очень абстрактно.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Потому что это в 95% случаев проще.

Да скорее наоборот, в 95% случаев на шелле с использованием существующих средств - сложнее.

Вернемся к backlight. `echo 75 | sudo tee /sys/class/intel_backlight/brightness' - это всего малая часть работы. Ведь нужно выставить яркость и после загрузки (откуда читать значение? на debian, slackware, arch?). И код восстановления значения яркости после загрузки, и количество действий по правке конфигов - в десяток раз больше, чем вышеупомянутая строчка `echo '. Вот тебе сложность. Причем это не сложность шелла, это сложность «ручек управления системой» и зоопарком конфигов.

И именно эту сложность намерены решить с помощью systemd. И после этого, твое выражение: «Если можно сделать на sh — надо сделать на sh. Потому что это в 95% случаев проще.» будет истиной. Пара команд на шелле - и ты бог и контроллируешь не только личный локалхост, но и большинство linux-систем. Вот это простота!

Deleted
()
Ответ на: комментарий от Deleted

Я говорил не об этом. Разумеется, что утилиты, которые делают set/get/store/restore надо писать на каких-то более приспособленных языках. Тем не менее, комбинирование этих самых утилит проще делать на Shell. И куда проще засунуть подобное в /etc/local.d/backlight.{start,stop}, чем писать систему инициализации на C.

anonymous
()
Ответ на: комментарий от tailgunner

переписывание 10 строк на shell в 426 строк на Си - это вин или фейл?

Где эти 10 строк то, с которых написали https://github.com/systemd/systemd/blob/master/src/backlight/backlight.c ? Покажи, тогда отвечу. Пока я не вижу ни вина не фейла.

Почему ты всё время называешь shell «интерфейсом»?

Шелл - это интерфейс управления системы человеком. Да, это язык, потому что так удобней, и это отлично. Sysfs - это API, интерфейс между одной программы и другой, одна из которой может быть на шелле. Но не только на шелле, а на других языках.

Но при управлении системой важно, что бы интерфейс был прост и гибок. Гибкость достигается языком - шеллу тут ставлю отлично; а простота достигается качеством библиотеки языка, для шелла это скрипты и команды системы - и тут, дело даже не в шелле, нужно делать скрипты и системные команды, типа `systemd-backlight', что бы библиотека была богатой, качественной и стандартной. А уже на шелле это будет, или на Си - дело десятое.

Deleted
()
Ответ на: комментарий от anonymous

Да какая разница, на чем писать систему инициализации. bash тоже написан на C. Да, синтаксис unit-файлов, по-моему, топорный, и видел обсуждения в рассылках того, что Леня с этим облажался, и сам так считаю. Я бы взял lua-подобие для unit-файлов. Но несомненный плюс системы инициализации systemd - она во многом декларативна. unit-ы должны быть декларативными, поэтому lua в прямом виде тут не катит

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

нужно делать скрипты и системные команды, типа `systemd-backlight', что бы библиотека была богатой, качественной и стандартной. А уже на шелле это будет, или на Си - дело десятое.

*пожимая плечами* Тем не менее переписывание скрипта на Си было объявлено «вполне эпик вином».

tailgunner ★★★★★
()
Ответ на: комментарий от Deleted

синтаксис unit-файлов, по-моему, топорный, и видел обсуждения в рассылках того, что Леня с этим облажался, и сам так считаю

+1

Но несомненный плюс системы инициализации systemd - она во многом декларативна

Но несмотря на это, инструмента валидации конфигурации нет. Здесь поцеринг тоже облажался. И код с функциями на сотни строк и десятками точек выхода - тоже лажа. Весь systemd - одна большая лажа.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Нет в этом проблемы. Потому что да, systemd - это не система инииализации. Это некий системный менеджер - стандартизируемые (процесс идет!) ручки управления linux-системами. Я имел ввиду, что СИ systemd - именно ту ее часть, которая СИ и является. Не стоит на этом внимание заострять.

И да, для такого большого и всепроникающего системного менеджера конфиги должны быть декларативные и на гибком языке, unit-ы топорны, но это лучше, чем кто-в-лес-кто-по-дрова на sh. (Сравни инит скрипты на доsystemd-шных дебиане, арче, слаке и генту - зоопарк же, не гооря уже о скриптах настроки других вещей: сети, управление питанием и т.п.)

Deleted
()
Ответ на: комментарий от Deleted

Да какого скрита? Покажи его. Где эти 10 строк?

Спроси intelfx - я не слежу за разработкой.

А может там не 10, а 50?

Может быть. А что, переписывание 50 -> 400 - это уже вин? Где граница?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Но несмотря на это, инструмента валидации конфигурации нет.

но сейчас хотя бы об этом можно задумываться (и люди задумываются!), и тут уже вопрос из серии «надо сесть, подумать, и сделать», а не рассуждение из серии «да вы чо, шутите, что это такое ваще». Огромный шаг, я считаю.

Следующим огромным шагом случится лет через 10 другое юное дарование, который будет знать не только сишечку, но и высокоуровневые правильные языки, да с математическим бекграундом.

Тут же как: в нужное время в нужном месте, человек с нужными качествами и мотивацией приложил свои усилия. Для управления этим стихийным вероятностным принципом цивилизация может предложить: повышение квалификации определенной группы людей (достаточно большой, что бы выбрать), системные механизмы поощрения (зарплаты, моральные ништяки) и время (типа,подождем, что получится из этого адского котла). Ну эт уже философия и оффтоп :)

Deleted
()
Ответ на: комментарий от tailgunner

там из этих 400 половина уже комментарии о лицензии, другие комментарии и пустые строки со скобочками '}'. Оставшаяся половина из 200 строк - логгинг и обработка ошибок. Так что при одинаковой функциональности разница должна быть с точностью до конструкций языка, +-. Мне то ваще всеравно Си это или шелл. А вот функциональность: логгинг, каменты, обработка ошибок - решает.

Deleted
()
Ответ на: комментарий от Deleted

Но несмотря на это, инструмента валидации конфигурации нет.

но сейчас хотя бы об этом можно задумываться (и люди задумываются!)

«Сейчас»? Проекту уже 4 года. И вполне очевидно, что стадия проектирования благополучно пропущена.

Следующим огромным шагом случится лет через 10 другое юное дарование

Поцеринга можно назвать «дарованием» только в кавычках. Так что я бы с удовольствием подождал 10 лет.

Для управления этим стихийным вероятностным принципом

Ы. Написание systemd - это нихрена не вероятностный процесс, это типичный ынтерпрайз-проект. Говно, которое протолкнул большой вендор.

там из этих 400 половина уже комментарии о лицензии,

Нет. Но в любом случае - где граница?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Проекту уже 4 года.

ядру больше 20 лет, оно развивалось стихийно, с постоянным рефакторингом и своими кризисами, а теперь само под покровом ынтнрпрайза.

это типичный ынтерпрайз-проект

как я и говорил - это лучшее что сегодня смогла родить цивилизация. Ждём дальше

моя позиция : до системд подобное даже не пытались воплощать, а ведь вещь то нужнаЯ! допилят.

Deleted
()
Ответ на: комментарий от tailgunner

Многие приводимые аргументы обсуждены в подобии технической дискуссии здесь и здесь.

anonymous
()
Ответ на: комментарий от theNamelessOne

Ну, хотя бы одна. Чтобы править комментарии. =|:}

qzxcvbnm
()
Ответ на: комментарий от Deleted

Да, синтаксис unit-файлов, по-моему, топорный, и видел обсуждения в рассылках того, что Леня с этим облажался, и сам так считаю.

Это где именно - примеры? По-моему синтаксис просто отличный.

Я бы взял lua-подобие для unit-файлов.

И получилось бы ещё одно непонятное говно. Причём поди ещё и тюринг-полное. Если уж экономить на парсере, то лучше s-выражений всё-равно ничего не придумаешь :)

anonymous
()
Ответ на: комментарий от anonymous

Лучше было бы сделать DSL, а не lua. Во всех нормальных проектах есть DSL. А чем мы лучше?

anonymous
()
Ответ на: комментарий от anonymous

А где пульса? Разве на свалке истори? Мне одному кажется, что пульса везде, в каждом дистрибутиве и практически на каждом дектопе?

lucentcode ★★★★★
()
Ответ на: комментарий от drfaust

надо всеръёз взяться за freebsd и послать арч в зад поттеринга.

1) поставил на старый ноут FreeBSD 10. UTF в консоли не умеет 2) suspend и hibernate не работает (ноутбуков простейший, Intel chipset 3) стал читать маны по systemd и писать юниты. Все просто и прозрачно.

a110c
()
Ответ на: комментарий от a110c

UTF в консоли фряшники не запиливают из принципа, хотя есть fbterm.
На нетбуке ASUS EEE 900HDA ещё 8.2 пахала без проблем (suspend и hibernate, Fn-кнопики - доставала спячка по Fn+F1 - часто промазывал по контролу и попадал на Fn), единственная проблема былы - wifi-ralink RT8030 - победил через ndis-скорлупу, впоследствии был сменен на к-то броадком...

drfaust ★★★★★
()
Последнее исправление: drfaust (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.