После двух месяцев разработки Линус Торвальдс анонсировал (https://lkml.org/lkml/2015/8/30/96) релиз ядра Linux 4.2 (http://kernel.org). Среди наиболее заметных улучшений: интеграция драйвера AMDGPU, поддержка стекового подключения LSM-модулей, новый метод формирования энтропии для генератора псевдослучайных чисел, новый классификатор пакетов Flower, проведена оптимизация ассемблерного кода для архитектуры x86, поддержка туннелей GENEVE, средства шифрования в F2FS, драйвер virtio-gpu с реализацией виртуального GPU, новая подсистема libnvdimm.В новую версию принято около 13 тысяч исправлений от более чем 1569 разработчиков, размер патча - 64 Мб (в два раза больше, чем патч с ядром 4.1, например, новый драйвер AMDGPU занимает более 400 тысяч строк кода). Изменения затронули 10926 файлов, добавлено 1081330 строк кода, удалено 282089 строк). Около 42% всех представленных в 4.2
изменений связаны с драйверами устройств, примерно 20% изменений имеют
отношение к обновлению кода специфичного для аппаратных архитектур, 12% связано с сетевым стеком, 4% - файловыми системами и 4% c внутренними подсистемами ядра.
Из наиболее интересных новшеств (http://kernelnewbies.org/Linux_4.2) можно отметить:
-
Дисковая подсистема, ввод/вывод и файловые системы- В F2FS, развиваемую компанией Samsung высокопроизводительную файловую систему для Flash-накопителей, добавлена возможность шифрования на уровне отдельных файлов и поддержка операций FALLOC_FL_ZERO_RANGE и FALLOC_FL_COLLAPSE_RANGE для управления резервированием пустых областей через вызов fallocate();
- В ext4 добавлена поддержка опции FALLOC_FL_INSERT_RANGE (https://lwn.net/Articles/629965/), позволяющей осуществить подстановку обнулённого блока в существующий файл через вызов fallocate();
- В XFS появилась возможность прямого доступа к устройствам постоянной памяти (persistent-memory), применяя интерфейс DAX;
- В файловой системе CIFS добавлена экспериментальная поддержка протокола SMB 3.1.1;- В модуле dm-cache, предназначенном для ускорения доступа к жестким дискам через применение кэширования на SSD-накопителях, добавлена (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... поддержка SMQ-кэширования (stochastic-multi-queue), решающего проблемы с большим потреблением памяти при кэшировании с привлечением нескольких очередей (multi-queue);
-
Память и системные сервисы- Код выборки по именам файлов переработан для исключения рекурсии, что позволило сократить нагрузку на стек, повысить надёжность работы сложных систем хранения и убрать лимит на глубину вложенных символических ссылок;
- В подсистему профилирования perf добавлена (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...поддержка функциональности PEBSv3 (Precise Event-Based Sampling), присутствующей в новых процессорах Intel. Улучшена поддержка возможностей Intel PT (аппаратный трассировщик CPU) и Intel CQM (мониторинг качества утилизации кэша). Значительно расширены возможности утилиты perf: в 'perf top' реализована возможность динамического включения/выключения событий, в 'perf probe' добавлена поддержка глобальных масок имён функций и возможность сбора данных о всех аргументах функций, проведена подготовка к внедрению многопоточного варианта команды 'perf report';
- В систему обработки данных от термодатчиков, добавлен новый power-allocator (https://lkml.org/lkml/2014/12/5/434), сочетающий раздельную обработку параметров нагрева отдельных элементов с попыткой поддержания общей температуры системы в заданных границах;
- Переписан ассемблерный код для архитектуры x86, переработан (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... и реструктуризирован код для взаимодействия с модулями операций с плавающей запятой (FPU);
- Добавлена новая подсистема ядра "libnvdimm (https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt)&... предоставляющая различные методы доступа к массивам энергонезависимой памяти (NVM, non-volatile memory), сочетающей производительность ОЗУ с возможностью постоянного хранения содержимого. Для процессора энергонезависимая память выглядит как обычное ОЗУ (отображается в пространство системной памяти в виде больших регионов физической памяти), но при этом данные не теряются после прекращения подачи энергии. Для записи данных в NVM-память представлены функции memremap_pmem(), memcpy_to_pmem() и wmb_pmem(). Обеспечена возможность представления регионов NVM-памяти в качестве отдельных виртуальных устройств. Через модуль "BTT" (block translation table) реализован слой для атомарного посекторного доступа к NVM-массивам, представленным в форме блочных устройств;
- Изменён подход к монтированию псевдо-ФС sysfs и /proc. Поддиректории для точек монтирования (например, /sys/debug) теперь специально помечены и монтирование допускается только в них. Добавлены средства (https://lwn.net/Articles/647757/) для контроля соответствия флагов для уже примонтированных и новых экземпляров псевдо-ФС (для монтирования в контейнерах);
-
Виртуализация и безопасность- Добавлен (https://lwn.net/Articles/642166/) новый код формирования энтропии для генератора псевдослучайных чисел, основанный на учёте отклонения времени повторного исполнения определённого набора инструкций на CPU (CPU execution time jitter), которое зависит от множества внутренних факторов и непредсказуемо без физического контроля над CPU. Новый код решает проблему с недостаточным числом источников энтропии на встраиваемых устройствах;
- В гипервизор KVM добавлена поддержка множественных адресных пространств и режима системного управления (SMM (https://ru.wikipedia.org/wiki/System_Management_Mode), System Management Mode). Данные возможности позволяют реализовать поддержку режима верифицированной загрузки (Secure Boot) для гостевых систем;
- Реализована возможность стековой организации (https://lwn.net/Articles/635771/) модулей LSM (Linux Security Modules), позволяющей выстраивать цепочки обработчиков, задействуя сразу несколько модулей. Например, теперь можно подключить специализированные LSM-модули в качестве надстройки поверх таких систем, как SELinux, Smack, TOMOYO и AppArmor.
- Поддержка устройства virtio-gpu (виртуальный GPU), которое пока ограничено возможностью ускорения 2D-графики;
-
Сетевая подсистема- Добавлен новый классификатор пакетов "Flower", который позволяет классифицировать пакеты на основе настраиваемой комбинации ключей и масок пакетов;
- Интегрирована поддержка туннелей GENEVE (http://tools.ietf.org/html/draft-gross-geneve-02) (Generic Network Virtualization Encapsulation);
- В подсистему netfilter добавлена поддержка классификации пакетов по времени их поступления (ingress-time);
- В сокетах Unix-domain обеспечена поддержка системного вызова splice() (https://en.wikipedia.org/wiki/Splice_%28system_call...
- Добавлен алгоритм контроля перегрузки (congestion-control), учитывающий отклонение величины ожидания (Delay-gradient (https://lwn.net/Articles/645115/));-
Оборудование- В состав ядра принят код драйвера AMDGPU (http://www.opennet.me/opennews/art.shtml?num=42078), разработанного для воплощения в жизнь новой стратегии продвижения драйверов для графических процессоров компании AMD, в рамках которой модуль ядра является полностью открытым, а проприетарный драйвер Catalyst будет включать лишь набор проприетарных библиотек, реализующих фирменные варианты OpenGL, OpenCL и т.п. Добавленный в ядро драйвер отвечает за поддержку GPU на основе GCN, начиная с R9 285 "Tonga" (семейство Volcanic Islands) и более новых;
- Возвращена поддержка архитектуры Renesas H8/300, которая несколько лет назад была исключена из ядра из-за заброшенного состояния и отсутствия сопровождающего. Новая реализация пер...
URL: https://lkml.org/lkml/2015/8/30/96
Новость: http://www.opennet.me/opennews/art.shtml?num=42843
> Расширены возможности драйверов для видеокарт Intel, NVIDIA (Nouveau) и AMD (Radeon);А можно поподробнее? В частности интересует NVIDIA:)
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nex... - вот это собирай, или жди 4.3_rc1
> А можно поподробнее? В частности интересует NVIDIA:)В нвидии в 4.2 ничего интересного нет. Там в 4.3 большой набор коммитов будет. Но в целом АМД и интель для любителей опенсорса как-то сильно интереснее...
Ясно, большое спасибо)
> Ясно, большое спасибо)Очень иллюстративно - сравнить форумы по амд и нвидии на форониксе.
Чему равно net.ipv4.tcp_congestion_control для Delay-gradient и какие userspace утилиты поддерживают создание туннелей GENEVE?
"cdg", судя по всему.
> Поддержка беспроводных чипов Mediatek MT7601UХорошая новость.
Раз уж такую тему затронули. Подскажите, какие сейчас самые лучшие микросхемы USB-WiFi из недорогих? RealTek 8188, MT7601U или старые Ralink?
берите realtek. Дрова под ralink/mediatek очень хренового качества (регулярные разрывы и т.п.) и практически не поддерживаются
Только вчера решил, что никогда не буду брать Realtek.
Красноглазил весь день, чтобы заставить правильно работать usb wifi адаптер. Официальный драйвер rtl8187 делает коннект не более 30-40кБ/с, как бы урезая в ноль канал. Гугление показало, что много лет пишут багрепорты на эту серию устройств, но ситуация не изменена до сих пор.
Не один офф. ndis-драйвер не встал нормально.
Странно, у меня Alfa AWUS036H с RTL8187L
Такого не замечал. Всё нормально работает.
Жаль только под OS X не заводится - приходится лайв линукс на флешке таскать.
очень зависит от ядра. дрова писались для старых ядер а в новых многое меняется и они устаревают. сам ковырялся с одним чипсетом вайфай+БТ, котрый типа на ура работает в форумах. И дрова есть от производителя. В итоге Азерос заказал. Он среди Броадкома, Реалтека оказался лучшим...
вот именно тем более что азэрос прошивку открытую имеет..
> вот именно тем более что азэрос прошивку открытую имеет..А еще там работают все мыслимые режимы. И даже глючность весьма умеренная. Из очевидных проблем: как AP держит только 7 клиентов (ограничение фирмвари по ресурсам встроенного проца).
> Такого не замечал. Всё нормально работает.Попробуй создать пару виртуальных интерфейсов, или там сделать packet injection произвольных пакетов в эфир (красиво и убедительно работает для демонстрации "безопасности" WEP-а всяким овощам, когда ты им показываешь их ключ через целых 5 минут).
> Жаль только под OS X не заводится
У эппла стандартный ответ: покупай гаджеты от эппла, по конской цене.
Впрочем, яблодро... понравятся коммиты в новый reaver. Где колоритно расписывается что у эппла просто нет никаких апи ни для чего. Поэтому все что придумали - дергать внешние утилиты. Вот такое вот хреновое лето^W апи.
Можно ссылку на коммиты?
Извините, но мне кажется вы пишите из параллельной вселенной. Долгое время использовал TP-Link 7200 на чипе Ralink, всё работало на ура, мощный адаптер на 500mW бьёт далеко если прикрутить направленную тарелочку из аллюминиевой банки.
Узнал о существовании более скоростного TP-Link 8200 с двумя антеннами, приобрёл, но тот оказался на чипе Realtek и отказывается работать в Linux напроочь. И на данный момент всё ещё не существует работающего драйвера, о чём так же пишут здесь: https://wikidevi.com/wiki/TP-LINK_TL-WN8200NDХотите идеальный Wi-Fi адаптер? Посмотрите на чип ath9k, он полностью свободен и не требует блобов, работает в Linux из коробки. Мне повезло с ноутбуком, в Asus X200MA именно такой Wi-Fi чип стоит.
И на этом ноутбуке ты собираешь свой CRUX?
Ага. :)
Не думал купить себе хотя бы Core i5?)
> Не думал купить себе хотя бы Core i5?)Отопитель воздуха в ближайшем ларьке - дешевле и отапливает лучше.
Я про АМД ничего не говорил)
> Я про АМД ничего не говорил)Я про компилодрочеров говорил :)
Там на linux-wireless на днях человек опубликовал новый драйвер и просит всех тестировать.
Девайс 0x2357 0x0100 как раз в категории untested. Не хочешь проверить? :)
> http://marc.info/?l=linux-wireless&m=144088309801117&w=2...
It currently supports station mode only.Да, это вам не ath9k...
ALFA NETWORK AWUS036NH на Ralink RT3070 отлично работает в Ubuntu/Kali, сейчас подключен к Raspberry Pi 2 Model B c Kali 2.0 на флешке)
>> Поддержка беспроводных чипов Mediatek MT7601U
> Хорошая новость.
> Раз уж такую тему затронули. Подскажите, какие сейчас самые лучшие микросхемы USB-WiFi
> из недорогих? RealTek 8188, MT7601U или старые Ralink?У меня дома есть ralink использовал для поднятия точки доступа, для спецефической задачи. Работает норм. Правдо нагрузки на точку большой небыло.
AR9271
> AR9271Идеальный вариант - ухитриться найти его соседа 7010, в паре с AR9xxx 2x2, тогда будет еще и 300Мбит. Но т.к. так дороже - такие свистки слегка экзотика.
Realtek, в моём случае 8192CU, не брать ни в коем случае. Симптомы те же, что описаны выше - скорость 30-40 кБит/с, канал при этом полностью забит. А вот Atheros (у меня AR9271) - берите смело. Драйвер в ядре качественный, правда придётся установить firmware-atheros, если у вас Debian. В Arch пакет linux-firmware поставится сам, если вы установите base и base-devel сразу (куда ж вы денетесь).
Лучшие - Atheros.
> Раз уж такую тему затронули. Подскажите, какие сейчас самые лучшие микросхемы USB-WiFi
> из недорогих? RealTek 8188, MT7601U или старые Ralink?Atheros :P. Его правда на фоне рыгалтеков и медиатеков сложнее найти. Зато работает все. Вплоть до monitor mode с packet injection или там нескольких VIFов на одном адаптере. Не говоря о том что чувствительность - на высоте.
>Поддержка устройства virtio-gpu (виртуальный GPU), развиваемого в рамках проекта Virgil.Ну наконец, полтора года ждал.
Надеюсь rt3290 уже нормально работать будет
А какие траблы с 3290 и с чего взяли, будто ситуация может исправиться?
Wifi работает без проблем с модулем rt2800pci. А вот с синезубом в этом безумном комбике (Ralink corp. RT3290 Bluetooth Subsystem: Hewlett-Packard Company Ralink RT3290LE 802.11bgn 1x1 Wi-Fi and Bluetooth 4.0 Combo Adapter)действительно давняя проблема.
Реализация в rt2800pci очень плохо держит коннект, и часто при слабом сигнале не подключается к точке. В то время как проприетарный rt3290st при равных условиях лучше держит коннект, а при хорошем сигнале - не теряет.
Мой rt3290 (драйвер rt2800pci):
* часто скорость падает практически до 0 (в основном, когда к точке доступа подключены другие устройства)
* плохо ловит слабый сигнал
* иногда реконнестится
* про Bluetooth вообще молчу
Почему не развивается JFS? Или развивается, но без фанфар?
IBM денег не выделяет?
> IBM денег не выделяет?IBM в свое время был одним из участников междусобойчика по созданию btrfs. JFS элементарно древний и не умеет ничего интересного. Все что он умел - он уже неплохо делает, а больше особо там и выжимать из такого дизайна нечего.
commit f76d94def5605fbec1de61218e91fe1002fd322f
Merge: 3aa2050 2645695
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Jul 16 16:28:28 2015 -0700Merge tag 'jfs-4.2' of git://github.com/kleikamp/linux-shaggy
Pull jfs fixes from David Kleikamp:
"A couple trivial fixes and an error path fix"
* tag 'jfs-4.2' of git://github.com/kleikamp/linux-shaggy:
jfs: clean up jfs_rename and fix out of order unlock
jfs: fix indentation on if statement
jfs: removed a prohibited space after opening parenthesiscommit 26456955719b79cc4a011b18221aa68f599f6b6c
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date: Wed Jul 15 12:52:47 2015 -0500jfs: clean up jfs_rename and fix out of order unlock
The end of jfs_rename(), which is also used by the error paths,
included a call to IWRITE_UNLOCK(new_ip) after labels out1, out2
and out3. If we come in through these labels, IWRITE_LOCK() has not
been called yet.
In moving that call to the correct spot, I also moved some
exceptional truncate code earlier as well, since the early error
paths don't need to deal with it, and I renamed out4: to out_tx: so
a future patch by Jan Kara doesn't need to deal with renumbering or
confusing out-of-order labels.
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>commit 9abea2d64ce93b6909de7f83a7f681f572369708
Author: Mikulas Patocka <mikulas@twibright.com>
Date: Thu Jul 9 18:05:15 2015 +0200ioctl_compat: handle FITRIM
The FITRIM ioctl has the same arguments on 32-bit and 64-bit
architectures, so we can add it to the list of compatible ioctls and
drop it from compat_ioctl method of various filesystems.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Ted Ts'o <tytso@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Почему не развивается JFS? Или развивается, но без фанфар?Потому что развивать там особо нечего. Ну сделали там TRIM. А так - файлуха без особых сильных сторон. Из нее более-менее выжали все на что годился этот дизайн. Что вам еще надо то?
А мне вот это заинтересовало:
>В файловую систему CIFS добавлена экспериментальная поддержка протокола SMB 3.1.1
А что такого крутого? Только, если взаимодействие с новейшими вендами типа windows 10.
В OS X насколько я понимаю до сих пор SMB 2
А что, вы много видели CIFS-*серверов* на базе OS X?
> В OS X насколько я понимаю до сих пор SMB 2И хрен с ней. Серверов на этом вообще днем с огнем не найдешь.
> Добавлен новый код формирования энтропии для генератора псевдослучайных чиселВот это по нашему!!! Надо каждый релиз пихать новый код сбора энтропии и самого генератора!
Криптоаналитеги и кульхацкеры саипутся искать дыры, коллизии и сингулярности. Пока вкурят,
пока натравят, пока систематизируют, а тут опа - и внизапно анонс... Ы-Ы-Ы-Ы-Ы-Ы :-P
> Надо каждый релиз пихать новый код сбора энтропии
> и самого генератора!И потом в рантайме случайным образом выбирать, который из них будет использоваться. ^^
>> Надо каждый релиз пихать новый код сбора энтропии
>> и самого генератора!
> И потом в рантайме случайным образом выбирать, который из них будет использоваться.
> ^^Для каждого запроса!
Псевдослучайным. И увеличить уровень рекурсии выбора псевдослучайного алгоритма псевдослучайным образом.
Есть риск, что худший алгоритм будет всегда себя выбирать
Чего сказать-то хотел?
Стандартные в таких случаях вопросы: в состав каких дистрибутивов это ядро войдет? В каких из ранее установленных ОС может быть смысл их ядро поменять на это? Насколько больше устройств в этой версии ядра стало поддерживаться? (А сколько не поддерживаемых в линуксе сейчас осталось?) Каким будет срок жизни этой ветки ядра?
И по состоянию насегодня- а какое ядро лучше подходит использовать на старом "железе"? (А там, думаю,- более одного варианта- смотря на какое подбирать).
Arch и Gentoo.
По остальным вопросам думай сам, иначе ты _ненужен_.
В Федоре тоже будет.
ubuntu заикалось что может успеют воткнуть в осенний релиз 4.2, но при желании в любую убунту можно поставить ручками пакет который можно стянуть с их же kernel team ppa.
я так и делал когда сидел на ubuntu 12.04.
Ну а тут, в арче, обычно всегда все как бы свежее. в тестинге появится наверно уже завтра, а может уже и вчера, а в обычных репах - через неделю-две.Старое железо - насколько старое? на pentium II уже ничего новее 3.2 не запустить, но таких, кому нужно i386, мне думается, не более 0,2%. И они сами разберутся, что им надо.
Длинной поддержки этой ветки пока не объявлялось, но опять же это более интересно в секторе embended.
а по поводу железа - вопрос в вакууме. Есть десятки разных железок, у которых один и тот же чип, и если его функциональность улучшена с новым ядром - то и этот неизвестный порядок устройст доавлен в список поддерживаемых девайсов, только надо для этого их ручками проверять. а сколько не поддерживается - не возможно такого списка создать пока устройства проивзодят много разных издателей. вот как будет всем заниматься один изготовитель, так настанет рай на земле, и будет список всего что поддерживается (надеюсь такого не будет).
Кто подскажет, планируется ли в новом драйвере AMD добавить поддержку R9 290, 290X, 280, 280X?
И 270/270X..
Нет. Только тонга, три фурика и будущие GCN. Для 2xx/3xx серий есть RadeonSI.
> Нет. Только тонга, три фурика и будущие GCN. Для 2xx/3xx серий есть
> RadeonSI.Или руки у меня из одного места растут, или еще что-то.. Но в Ubuntu 15.04 / Fedora 22 при игре в CS: GO получаю зависания видеокарты. Разница между дистрибутивами только в том, что Ubuntu падает полностью. Нормально работает только 3.15.4, если не ошибаюсь.
Во время обычной работы (не игр), ничего не "падает".
Да, у меня Radeon R270X
Возможно, следует написать багрепорт. Или использовать каталист.
Лучше использовать Nvidia)
> Лучше использовать Nvidia)А не ты ли, нехороший человек, плакался что у тебя там на невидии баги, которые чинить никто не собирается? АМДшники баги чинят, в отличие от. У них нормальный багтрекер есть. Можно отловить живых разработчиков в IRC. Ну и так далее. И если им дать нормальную диагностику (желательно простые шаги воспроизведения) - баг зашибут довольно быстро.
> Лучше использовать Nvidia)Не, спасибо. Вчера мне плясков с бубном на работе хватило с GT 9600: Nouveau только на один монитор может передавать изображение, хотя видит оба. Последний nvidia драйвер не поддерживает ее. Даже банально консоль отказался показывать. После загрузки в single mode удалось таки понять, что надо старую версию драйвера поставить + вывод dmesg | grep -i nvidia приятно удивил тем, что видеокарта инициализирована, но не найдена :D
Не старую версию, у них обновляемые ветки.
> Возможно, следует написать багрепорт. Или использовать каталист.Каталист юзал, но в нем сильная просадка FPS была.
Багрепортов полно было (https://bugs.freedesktop.org/buglist.cgi?quicksearch=radeons... но ничего внятного пока не сделали :(
> Каталист юзал, но в нем сильная просадка FPS была.Давно замечено что MESA вообще как-то сильно менее дергано рендерит чем каталист, что нравится любителям шутеров. Сложно целиться когда FPS дерганый :)
> но ничего внятного пока не сделали :(
А у меня все мыслимые fault'ы ушли с новой MESA из oibaf ppa.
> Или руки у меня из одного места растут, или еще что-то.. Но
> в Ubuntu 15.04 / Fedora 22 при игре в CS: GO получаю зависания видеокарты.Ну так подцепи PPA по типу Oibaf и посмотри - ушла ли проблема. И ядро свежее поставь.
> падает полностью. Нормально работает только 3.15.4, если не ошибаюсь.
Попробуй как раз ядро 4.2 поставить. И свежую MESA. Там как раз с 270(X) и около было одно время поломано, но в актуальных версиях софта все починено.
>> Или руки у меня из одного места растут, или еще что-то.. Но
>> в Ubuntu 15.04 / Fedora 22 при игре в CS: GO получаю зависания видеокарты.
> Ну так подцепи PPA по типу Oibaf и посмотри - ушла ли
> проблема. И ядро свежее поставь.Oibaf/graphics-drivers/ стоит, раньше проблему не решало. Сейчас не знаю, проверю.
>> падает полностью. Нормально работает только 3.15.4, если не ошибаюсь.
> Попробуй как раз ядро 4.2 поставить. И свежую MESA. Там как раз
> с 270(X) и около было одно время поломано, но в актуальных
> версиях софта все починено.В свое время я перепробовал кучу разных версий ядер: drm-next, ubuntu-kernel, stock (собирал из сорцев). Проблема так и оставалась.
Что самое примечательное, так это то, что в федоре этот баг замечан не был. Хотя может просто лень было нормально тестировать.
> Oibaf/graphics-drivers/ стоит, раньше проблему не решало.Раньше - понятие растяжимое. Если это было год назад - с тех пор многое изменилось. А если 2 дня назад - с тех пор изменилось мало что.
> Сейчас не знаю, проверю.
У меня все известные случаи такого плана поудавились. Чего и другим желаю.
> (собирал из сорцев). Проблема так и оставалась.
Возможно, амдшники просто не в курсе именно этого сценария.
Впрочем, я без версий софта тоже много полезного не скажу. Скажем LLVM до 3.6.2 мог генерить трэшовый код, ставивший GPU колом. В LLVM вообще, баг на баге и багом погоняет. В oibaf нынче живет минимально-юзабельная версия LLVM. Все что тревнее этого с RadeonSI просто не того. MESA до некоего момента - умела провоцировать зависоны GPU, в ядре были баги с управлением GPU VM и буферами. Ну в общем, SI относительно новые и им все эти компоненты свежими нужны. Если даже с распоследним ядром, свежей MESA и LLVM оно падает - брать амдшников за жабры.
Есть 2 коронных приема которые могут их убедить починить баг:
- Можно попробовать сделать bisect и ткнуть их носом в коммит. Если немного понимать как драйвер устроен и вы в состоянии понять что коммит не бред - way to go!
- Можно попробовать записать реплей операций OpenGL в файл apitrace. Если у амдшников реплей повиснет - дело в шляпе (но вот то что у них точно такой GPU есть - не факт).> Что самое примечательное, так это то, что в федоре этот баг замечан
> не был. Хотя может просто лень было нормально тестировать.Там были какие-то редкие но меткие локапы в ряде нагрузок. У меня все баги этого типа поизвелись с текущей версией компонентов из oibaf и ядром 4.2. Кстати LLVM 3.7 уже вышел и по идее надо его уже смотреть. Oibaf в этом плане протупляет немного - у него все с LLVM 3.6.2 собрано. Но у меня оно перестало дохнуть даже так. Все мои known bad сценарии вешавшие GPU более не работают... (их было 5 штук, два по линии OpenGL и 3 по линии OpenCL - заработало всё).
Мне кажется, что 5.0 уже не за горами.
> новый драйвер AMDGPU занимает более 400 тысяч строк кодаБедное ядро, столько шлака в него пихают, и всё без толку)
Как это не нужно?
Венда то на десктопах используется, там да - не нужно.
А линукса на десктопах нет. Зато есть в серверах, а там надо. Или в мобилках - тот же ubuntu touch запускается как LXC контейнер.
Даже Docker не нуждается в гипервизоре KVM. То есть отдельного kqemu более чем достаточно. Хоть убей не пойму зачем тащить в ядро, то, что даже внешним блобом спокойно может работать. Конечно сейчас популярны VDS, но машинам под виртуализацией зачем уметь виртуализировать? Виртуальные матрёшки создавать?
> А линукса на десктопах нет.У меня - есть. Так что не надо тут врать.
>Венда то на десктопах используется, там да - не нужно.
>А линукса на десктопах нет.Лол што? Теюя нае^обманули. У меня венды 15 лет нет вообще и исключительно линух на десктопах
> До фанатиков не дойдёт, что не всё, что выполняется в пространстве ядра,
> должно быть его неотъемлемой частью. А тем временем всё больше пунктов
> конфига не отключаются и делают ядро лишь жирнее и тормознутей. Начиная
> по моему с версии 2.2, функционал ядра почти не улучшался, лишь
> добавлялись драйвера. Необходимость наличия виртуализации в ядре вообще абсурдна. Как
> в винде без всего этого мусора виртуальные машины работают? А ведь
> этот функционал практически никому не нужен.Вот так и работают. То повиснут, то потухнут...)))
Даешь фаервол в юзерспейсе как у венды!
> по моему с версии 2.2, функционал ядра почти не улучшался, лишь добавлялись драйвера.Ну кто тебе виноват, что ты нефига не понимаешь в ядрах и твое мнение ошибочно.
> Необходимость наличия виртуализации в ядре вообще абсурдна. Как в винде без всего этого мусора виртуальные машины работают?
Они добавляют в систему свой драйвер, который работает как раз на уровне ядра. А Hyper-V вообще идет в комплекте с виндой, начиная с win server 2008. Но ты ведь и в винде дальше переустановки не разбираешься.
> А ведь этот функционал практически никому не нужен.
Не у всех использование компьютера заканчивается запуском браузера и еще пары приложений.
> А Hyper-V вообще идет в комплекте с виндой, начиная с win server 2008. Но ты ведь и в винде дальше переустановки не разбираешься.Ну в хомячковых версиях венды его нет.
Windows 10 Pro, можно доставить через "Программы и компоненты".
В хоум ваще ничего нет из полезностей. Ни хайпер-ви, ни даже битлокера. Тупо запускалка игрушек.
> В хоум ваще ничего нет из полезностей. Ни хайпер-ви, ни даже битлокера.Ну а в линухе зато можно даже на распоследнем юзерском ноуте запустить виртуалку. И диск зашифровать. При том - опенсорсной реализации шифрования доверия как-то сильно больше, если что.
> Ну в хомячковых версиях венды его нет.Какие-то обрубки есть даже там. Оно нынче умеет грузиться с VHD "дисков" и прочая. Но ессно у MS хомяки в пролете - хотите вкусные плюшки? Извольте заплатить штуку грина за серверную редакцию. Хоть она ничем таким и не отличается, кроме бейджика, а хомяк-редакция искусственно обкоцана.
> Ну кто тебе виноват, что ты нефига не понимаешь в ядрах и
> твое мнение ошибочно.Ну так скажи, что такого нужного добавили в ядро, что должно висеть в памяти всех десктопов и серверов? Тот же iptables не всегда оптимальное решение и как его заменить или обновить без ядра? Да никак, только вырубить, ибо гвоздями прибит к ядру.
> Они добавляют в систему свой драйвер, который работает как раз на уровне
> ядра. А Hyper-V вообще идет в комплекте с виндой, начиная с
> win server 2008.Это нужно только для лучшего контроля за ресурсами гостя, работать всё может и без него.
> Не у всех использование компьютера заканчивается запуском браузера и еще пары приложений.
Веб-сервера, ftp-сервера, mail-сервера, nfs/cifs/smb-сервера, сервера терминалов, чаты, Docker не нуждаются в гипервизоре. Вот это я и называю большинством. Но тянут его в ядро все по умолчанию.
> Ну так скажи, что такого нужного добавили в ядро, что должно висеть
> в памяти всех десктопов и серверов?А оно всегда и не висит. Тот же AMDGPU на 400К строк - отдельный модуль. Нету видяхи - ну и модуль такой не вгрузится. И в памяти не висит, соответственно. И так с большинством дров.
А если уж память оптимизировать - вышвырнуть значок принтера на бидоне из трея, одним махом отыграв 30Мб RSS - результативнее чем крохоборстсовать в ядре, пардон. Хотя когда весь юзермод обрублен - можно и ядро обрубить. Пример как это делается - можно посмотреть в openwrt, например. Ему по минимуму хватает 16Мб, хотя лучше 32. Там ессно не только ядро при этом работает :)
> Тот же iptables не всегда оптимальное решение и как его заменить или обновить без ядра?
Iptables - это программа такая. Интерфейс к подсистеме netfilter. И там туева хуча модулей с фильтрами на все вкусы. Если не нравится программа iptables - есть например nftables. Ему кой-какие фичи из новых ядер нужны, но это уже другая история. На новых ядрах будет работать и то и другое.
> Да никак, только вырубить, ибо гвоздями прибит к ядру.
Netfilter то? Ну да, должно же ядро как-то пакеты фильтровать. А без ядра не получится - в конце концов ядро и рюхает все сисколы. Ему и виднее, соответственно, кто, куда и зачем хотел.
> Это нужно только для лучшего контроля за ресурсами гостя, работать всё может и без него.
Ну так в линухе тоже много чего сделано по причине "а вот так лучше работает". Кроме всего прочего - майнлайновые драйвера работают лучше чем out of tree, с ними намного меньше дурных проблем на ровном месте.
> Веб-сервера, ftp-сервера, mail-сервера, nfs/cifs/smb-сервера, сервера терминалов,
> чаты, Docker не нуждаются в гипервизоре.Очень весело получается, когда у вас после взлома FTP тырят всю почту, дефейсят сайт, вливают вирье на шары и прочая. А вот контейнеры могут частично минимизировать урон, при том не требуя затрат денег на новые железные сервера. Это компромисс, разумеется. Но лучше чем когда у вас после взлома FTP уносят почтовую базу.
> Вот это я и называю большинством. Но тянут его в ядро все по умолчанию.
Ядро штука модульная и конфигурируемая. Дистроклепатели его всяко собрают так как им надо. Если вам надо что-то еще - извольте сами конфигурять себе все это.
>> Ну кто тебе виноват, что ты нефига не понимаешь в ядрах и
>> твое мнение ошибочно.
> Ну так скажиСтоп. Вы вылезли с глупыми утверждениями -- Вам и штудировать матчасть.
iptables(8) -- вообще юзерспейс.
> А тем временем всё больше пунктов конфига не отключаются и делают ядро лишь жирнее и тормознутей.Это какие? По-моему наоборот появился CONFIG_EXPERT (Configure standard kernel features (expert users)).
> Это какие? По-моему наоборот появился CONFIG_EXPERT (Configure standard kernel features
> (expert users)).Например cgroups мне совершенно не нужен. Как его выпилить?
Или вот: Load all symbols for debugging/ksymoops (KALLSYMS). Тоже всегда ставится в yes, но совершенно непонятно зачем оно мне нужно. Я ядро дебажить не собираюсь.
Кукаретик не осилил конфигурацию ядра?http://storage4.static.itmages.ru/i/15/0831/h_1441016058_358...
http://storage6.static.itmages.ru/i/15/0831/h_1441016083_212...
Если make config пропускает эту опцию, то очевидно, что и menuconfig её сбросит в положение по умолчанию.
Если человек не умеет конфигурировать и собирать ядро, то очевидно, что он будет винить ядро, да.
Надо же в 4.0 оно ещё выглядело так http://storage6.static.itmages.ru/i/15/0831/h_1441017120_381...
Смотри, какой я волшебник: http://storage3.static.itmages.ru/i/15/0831/h_1441017392_323...
Что это за скайнет у тебя на экране?
> Смотри, какой я волшебник:А у тебя забавно выглядят окна. Это что за оконный манагер и оформление?
А волшебство у меня имхо веселее :P (записывая конфиг для очередной ARMовской борды и запуская make CROSS_COMPILE ... поверх которого вон тот debootstrap'нутый rootfs ща взлетит).
Compiz и Emerald
> Compiz и EmeraldА, понятно. А что за тема у шапки окна? Футуристичненько так, скайнетообразненько :). Готов поспорить, юзеры десятки завистливо щелкают клювами, глядя на это.
>> Compiz и Emerald
> А, понятно. А что за тема у шапки окна? Футуристичненько так, скайнетообразненько
> :). Готов поспорить, юзеры десятки завистливо щелкают клювами, глядя на это.Не спорь, мы это уже в 2003 проходили. Тошнит от этой прозрачности, от дрожащих
и плавающих окон, от вращающегося куба, эффекта сжигания окна при закрытии...
Подрочить недельку и выкинуть.
Тошнит, пардон, от долбаных одноцветных значков, на которые приходится полчаса пялиться до того как поймешь, многоуровневый это клипборд тут был, или настройки сети. От окон "на дворе Win 3.1 for Workgroups", ой, простите, восьмерка, или нет, десятка. С инновацией "мы тут опять запилили меню пуск" - ну прямо мушкетеры, 20 лет спустя. Я конечно понимаю что сложное это дело - продать один и тот же крап лохам в пятый раз подряд. Приходится изгаляться. Придумывать всякие мегаконцептуальные прямоугольники вырубленые топором, а-ля 1995 год. Всякий "material design" и что там еще за маркетинговый булшит я забыл.А такой и-фейс нативно смотрелся бы на полупрозрачном дисплее, HUD в шлеме VR и прочая, имхо.
> Тошнит, пардон, от долбаных одноцветных значков,Без понятия об чём вы. У меня Xfce и никакого композита, проц и видюху только греют.
А делать из Рабочего Стола (читать три раза), клоунское шоу, уже писал - онанизм от отсутствия работы.
С таким же успехом, можно на реальном столе устроить цирк и вращающихся стикеров, дрожащих стопок документов,
болтающихся на резинке степлера, ножниц, маркеров... Во веселуха.
> и никакого композита, проц и видюху только греют.А мне композит нравится. Даже не столько эффектами, сколько нормальным vsync везде и всюду. И вот что-что а проц и видюха у меня холодные. Проц буквально комнатной температуры. GPU на градусов 5 теплее комнатной температуры. Что там греется? Там вентиляторы почти остановлены на холостом ходу.
> А делать из Рабочего Стола (читать три раза), клоунское шоу,
Ты так говоришь, как будто это должно выглядеть как стол мясника.
> уже писал - онанизм от отсутствия работы.
А когда ты готов кушать любое д-мо, поздравляю - тебе сели на шею, при том весьма плотно.
> болтающихся на резинке степлера, ножниц, маркеров... Во веселуха.
Кар-кар-кар. Чего раскаркался то? Неужто нвидия глючит с компизом? Или у нее просто гуево с управлением питанием или стабильностью?
> А такой и-фейс нативно смотрелся бы на полупрозрачном дисплее, HUD в шлеме
> VR и прочая, имхо.В шлеме тем более 10-15 минут протянешь.
Переделал BlueGlass. Насчёт юзеров - кому-то нравится, кому-то нет) Мне всё равно, т.к. сам я в светлых окружениях работать долго не могу - глаза устают, а такой бирюзовый цвет очень мягок для глаз.
> Переделал BlueGlass.ИМХО получилось прилично: глаза не мозолит и при том не выглядит как г-но. Ну в общем таким скрином и похвастаться не стыдно, особенно если сам что-то переделал. Что бы там павлин не каркал про то как его запрягли на работе до состояния когда он темку нарисовать не может.
>> Это какие? По-моему наоборот появился CONFIG_EXPERT (Configure standard kernel features
>> (expert users)).
> Например cgroups мне совершенно не нужен. Как его выпилить?CONFIG_SCHED_AUTOGROUP = n
CONFIG_CGROUPS = n> Или вот: Load all symbols for debugging/ksymoops (KALLSYMS). Тоже всегда ставится в
> yes, но совершенно непонятно зачем оно мне нужно. Я ядро дебажить
> не собираюсь.CONFIG_EXPERT = y
CONFIG_KALLSYMS = n
Ну так и в системд можно не собирать какой-нибудь journald, например ;)
> Ну так и в системд можно не собирать какой-нибудь journald, например ;)1. Не надо путать ядро с userspace.
Вопросы не риторические. Мне действительно любопытно:
2. Как при этом будет поживать логирование? Можно ли будет присосаться в syslog-ng?
3. Можно ли journald использовать без systemd (утверждается, что это независимые приложения)?
4. Можно ли systemd использовать без udev (но с mdev) и dbus?
> 1. Не надо путать ядро с userspace.И то и другое попадает в категорию системного софта. И потому может использовать похожие подходы, имхо.
> 2. Как при этом будет поживать логирование?
А как настроишь - так и будет поживать. Его "встроенный" журнал - ну, сервис. Ведущий журналы и вывешивающий некое апи для работы с ними. На мой вкус, кстати, более логичное и структурированное, чем то что было до него. Если этот сервис не нравится, его можно не запускать, и даже не собирать. При этом пролетит его апи логгирования, что логично. Если сообщения прогоняемые программами через это апи все-таки интересовали, можно все-таки запустить сервис, но, например, запретить ему создавать его бинарные журналы. И вместо этого врубить редирект в другой логгер.
Всякий там продолб сообщений до того как взлетит этот ваш альтернативный логгер - извините, на вашей совести как вы это обтяпаете. До Поттера на такие вещи все вообще просто клали с прибором, а вжoпyyжаленность началась лишь когда поцтер показал что это можно нормально обтяпать сокет-активацией :)
> Можно ли будет присосаться в syslog-ng?
Смотря что значит "присосаться в syslog-ng". Наличие systemd никак не мешает syslog-ng работать так же как и раньше. Если имеется в виду "редиректнуть сообщения journald'шного апи" - можно. Хоть и потребует висения journald (вести бинарные журналы ему при этом не обязательно).
> 3. Можно ли journald использовать без systemd (утверждается, что это независимые приложения)?
Вот это я не знаю. Честно говоря такой вопрос я вижу впервые. По моим наблюдениям - в опеосорсе нет такого понятия как нельзя. Но бывает понятие "сложно". Является ли это именно тем случаем - не знаю, не проверял. Не было у меня такой цели в жизни как запустить journald отдельно от всего.
> 4. Можно ли systemd использовать без udev (но с mdev) и dbus?Без dbus - можно, хоть и не лучшая идея на свете. И, кстати, когда в ядро впилят kdbus, связка sdbus+kdbus, достаточная для работы с dbus-ом будет сильно компактнее того монстр-демона. И апи у либы куда как лучше.
Без udev - штатно в красивом и готовом виде так вроде не предусмотрено, но какой-то неотъемлимой частью systemd udev технически не является. В том плане что если его не будет - systemd этого не заметит особо.
Сказ про ломовое потребление ресурсов - идет лесом. Вон вам "ломовое потребление ресурсов": https://github.com/jdub/openwrt-systemd - там же можно посмотреть на пример сильного урезания системды под совсем микроскопическую эмбедовку.
А так - правда жизни такова, что проще всего - ходить протоптанными дорожками. А переть своей дорогой через бурелом, особенно первому - варьируется! И вы знаете, на мою точку зрения, даже если mdev прикрутить окажется не идеально просто - это не поцтер плохой строитель дорог, а это у вас какой-то экзотичный маршрут. Зачем он именно такой - я не знаю. Наверное из спортивного интереса. Ну коли так - ок, вот вам поприще, где можно попотеть, если делать не...й :).
Особенно меня умиляет во всей этой пьесе сказ про всякую эмбедовку, особенно со стороны всяких пользователей генты. Это при том что я эту эмбедовку разрабатываю, а подходы генты... ну мне кажется более прагматичным набрать рутфс дебутстрапом :P.
>> Это какие?
> Например cgroups мне совершенно не нужен. Как его выпилить?Ой зря, одна из немногих рулезных вещей в ядре линя.
Лучше поднапрячься, изучить и затюнинговать систему.
Даже самый дрищовый компьютер будет летать как 100500-ядерный.
>>> Это какие?
>> Например cgroups мне совершенно не нужен. Как его выпилить?
> Ой зря, одна из немногих рулезных вещей в ядре линя.
> Лучше поднапрячься, изучить и затюнинговать систему.
> Даже самый дрищовый компьютер будет летать как 100500-ядерный.С этого места поподробнее.
> Это какие? По-моему наоборот появился CONFIG_EXPERT (Configure standard kernel features
> (expert users)).Да и ядро жирнее не стало - все так же взлетает на мелких железках с openwrt.
Дополню. Все хаят systemd, за то, что тянет внутрь себя слишком много функциональности. Но совершенно не замечают того, что ядро занимается тем же самым.
systemd тянет в себя все подряд и зачастую то, что к системе инициализации не имеет никакого отношения. Вдобавок дублирует и завязывает на себя то, что уже было написано, отлажено и работало без него.Если бы systemd позиционировал себя как отдельная ОС (типа как android), то критики было бы на порядок меньше.
Ядро включает в себя только то, что характерно для ядер и что нужно для работы с железом. При этом оно имеет гибкую систему конфигурации и может оставаться работоспособным в минимальной конфигурации. Излишней завязки user space за какие-то сложные подсистемы ядра тоже не наблюдается.
Большая часть подсистем и драйверов развиваются отдельными группами вне ядра (то есть фактически являются отдельными проектами) и лишь периодически синхронизируются с остальными подсистемами и сливаются в кучу для удобства пользователя. Также такой подход позволяет искать и внедрять новые конкурирующие решения, не ломая при этом старых.
А systemd и не является системой инициализации, лол.> При этом оно имеет гибкую систему конфигурации и может оставаться работоспособным в минимальной конфигурации
Как и systemd.
> А systemd и не является системой инициализации, лол.А чем он по-вашему является?
>> При этом оно имеет гибкую систему конфигурации и может оставаться работоспособным в минимальной конфигурации
> Как и systemd.Без d-bus и udev работает?
> А чем он по-вашему является?Открываешь man systemd и читаешь: "systemd is a system and service manager for Linux operating systems". Краснеешь от стыда.
> Без d-bus и udev работает?
А ядро будет работать, если выставить "n" по всем опциям в конфиге?
>> А чем он по-вашему является?
> Открываешь man systemd и читаешь: "systemd is a system and service manager
> for Linux operating systems". Краснеешь от стыда.А чем по-вашему занимается система инициализации? И где раньше был "system and service manager"?
>> Без d-bus и udev работает?
> А ядро будет работать, если выставить "n" по всем опциям в конфиге?Аналогия не корректна. На данный момент есть другие систему инициализации, которые могут работать без d-bus и udev.
> А чем по-вашему занимается система инициализации?Системный менеджер и система инициализации это одно и то же, по-твоему?
> И где раньше был "system and service manager"?
А где раньше у Линукса была нацеленность на универсальное ядро общего назначения? Это изначально была фан-игрушка студента. А UNIX так вообще был запускалкой игры. А GTK - тулкитом для графического редактора)
> На данный момент есть другие систему инициализации, которые могут работать без d-bus и udev.
А есть ядра, которые могут работать без всяких ФС в себе. Например, HURD и MINIX.
>> А чем по-вашему занимается система инициализации?
> Системный менеджер и система инициализации это одно и то же, по-твоему?В общем - да.
>> И где раньше был "system and service manager"?
> А где раньше у Линукса была нацеленность на универсальное ядро общего назначения?
> Это изначально была фан-игрушка студента. А UNIX так вообще был запускалкой
> игры. А GTK - тулкитом для графического редактора)То есть до systemd, система обходилась без настройки и запуска сервисов?
>> На данный момент есть другие систему инициализации, которые могут работать без d-bus и udev.
> А есть ядра, которые могут работать без всяких ФС в себе. Например,
> HURD и MINIX.Я могу показать систему (десктоп/ноутбук) работающую без udev/d-bus, вы можете показать десктоп работающий на HURD или MINIX без ФС?
> То есть до systemd, система обходилась без настройки и запуска сервисов?Ну то-есть до системд мне надо было много чего костылировать и педалировать самолично. И я рад что поцтер взял на себя многие из этих вещей. Говоря начистоту, я бы не очень хотел выписывать логику дележа вачдога самолично. Нет, там "ничего такого с чемы мы бы не справились", но на написание такой штуки придется убить энное время.
> Я могу показать систему (десктоп/ноутбук) работающую без udev/d-bus,
А еще можно программу набивать тумблерами на шине, заассемблировав на тетрадном листочке. До сих пор так катит, через JTAG какой-нибудь. Или вон на хабре - для ваших атмег пример программирования "на необитаемом острове" есть.
> десктоп работающий на HURD или MINIX без ФС?
Смотря что понимать под "без ФС". Да и концептуальные системы без ФС - есть. А то что all концепция файлов кажется простой, логичной и понятной и поэтому без файлов они как оказалось не хотят - дргой вопрос :)
В тред врывается педалист-велосипедист юзер321, с вестью о спасении Поттеринговом от прежней, портянской, вечнокостыляющей-все-подряд жизни.Возрадуемся за душу, некогда дергающую напрямую сиськолы ядра из портянок на баше с обвязками на си для управления виртуалками. Он нашел покой рукам своим. Аминь, брат.
А вот НеХейтерТипа. Как всегда конструктивный и культурный. Удачи в таком подходе к делу, долгих лет вашим диванам и всего такого прочего.
>> То есть до systemd, система обходилась без настройки и запуска сервисов?
> Ну то-есть до системд мне надо было много чего костылировать и педалировать
> самолично. И я рад что поцтер взял на себя многие из
> этих вещей. Говоря начистоту, я бы не очень хотел выписывать логику
> дележа вачдога самолично. Нет, там "ничего такого с чемы мы бы
> не справились", но на написание такой штуки придется убить энное время.Естественно у systemd есть свои сильные стороны в определенных ситуациях.
Но ведь вы не будите утверждать, что до systemd система работала без настройки и сервисов. Просто эти действия происходили иначе.
>> Я могу показать систему (десктоп/ноутбук) работающую без udev/d-bus,
> А еще можно программу набивать тумблерами на шине, заассемблировав на тетрадном листочке.
> До сих пор так катит, через JTAG какой-нибудь. Или вон на
> хабре - для ваших атмег пример программирования "на необитаемом острове" есть.Это разные вещи - без systemd/udev/d-bus система проще для полной отстройки для себя, так как в целом работа системы более прозрачна.
>> десктоп работающий на HURD или MINIX без ФС?
> Смотря что понимать под "без ФС".В контексте обсуждение - тоже что и без udev/d-bus, то есть отсутствуют в системе напрочь.
> Да и концептуальные системы без ФС
> - есть. А то что all концепция файлов кажется простой, логичной
> и понятной и поэтому без файлов они как оказалось не хотят
> - дргой вопрос :)Таки да :)
> Естественно у systemd есть свои сильные стороны в определенных ситуациях.Я бы сказал что у него одна сильная фича: избавляет от туевой хучи дурного велосипедизма. И показывает что администрирование системы вовсе не обязано быть синонимом понятий "геморрой" и "много долботни на ровном месте".
А то что оно вот такое - на половину вообще не системд претензии. Кто виноват что из скриптов не катит делать сисколы, а 20 напрочь разных утилит, писаных разными людьми в разное время - неудобно админить? Там и в апях то разнобой знатный, так что соваться прописывать какие-нибудь ограничения вызовов через seccomp без системд рискнет не каждый первый. А когда это директива в конфигах - почему бы и нет?
> Но ведь вы не будите утверждать, что до systemd система работала без
> настройки и сервисов. Просто эти действия происходили иначе.Просто эти действия требовали много плясок с бубном, а некоторые вещи были "not feasible". Ну то-есть вы же понимаете что я не могу убить на кодинг запускалки столько же времени сколько на кодинг сервисов, ради которых все затевается, правда? Поэтому на практике все придет к халтуре, джамшутингу и бустанию всех мыслимых фич, в ущерб всему. Большинство инит скриптов это отлично иллюстрируют.
> Это разные вещи - без systemd/udev/d-bus система проще для полной отстройки для
> себя, так как в целом работа системы более прозрачна.Без systemd по моему опыту большинство виденых линуксных систем как-то так по жизни вообще кладет на всякое там обслуживание вачдога. И при зависоне - требует живого юзверга, жмущего резет или передергивающего питальник. А когда этого юзера нет... эм... получается не комильфо. Ну вон в openwrt например, обслуга вачдога, конечно, есть. Но если встанет колом какой-то важный для работы железки сервис - традиционно будут опаньки. И все эти runit, monit и прочая прекрасно. Только слегка не то. Скажем, сервис может и не быть сетевым в плане доступности портов на listen. И вообще, довольно так себе критерий живости программы. Ну вот скажем поливалка цветов, щелкающая релюхами по таймеру. Тот кто щелкает релюхой - не обязан быть сетевым сервисом. И даже если оно управляется через веб, это совсем не значит что я хочу иметь дело с сетью в именно той проге, которая релюхой клац-клац. А вот если прога повиснет - клац-клац релюхой сорвется. FAIL.
> В контексте обсуждение - тоже что и без udev/d-bus, то есть отсутствуют в системе напрочь.
В *nix-like совсем уж без файлов как-то тяжко - там парадигма "все - файл".
> Таки да :)
Ну да. Я видел пару уродцев, типа пальмоси, где все пытались совать в БД, чтоли. Ну их таких! При работе с такой системой возникает ощущение что мне оторвали руки и ноги, поэтому печатать на клавиатуре теперь можно исключительно носом. Результативность взаимодействия с системой - на таком уровне. ФС как таковая и есть БД. Только простая и низковровневая, так что покрывает все мыслимые юзкейсы а не пытается с пеной у рта доказать что "да и фиг с ним, с открытием аттача из почты другой программой".
>> Естественно у systemd есть свои сильные стороны в определенных ситуациях.
> Я бы сказал что у него одна сильная фича: избавляет от туевой
> хучи дурного велосипедизма. И показывает что администрирование системы вовсе не обязано
> быть синонимом понятий "геморрой" и "много долботни на ровном месте".Это если systemd умеет делать то, что нужно. А вот внедрить в него то, чего он не умеет, будет на порядок сложнее, чем в простую инит систему.
Пример того как у меня работает сеть на ноуте я приводил ранее:
http://www.opennet.me/openforum/vsluhforumID3/100356.html#434Не уверен, что это легко получится реализовать через systemd и не получить различных косяков в совершенно неожиданных местах.
> А то что оно вот такое - на половину вообще не системд
> претензии. Кто виноват что из скриптов не катит делать сисколы, а
> 20 напрочь разных утилит, писаных разными людьми в разное время -
> неудобно админить? Там и в апях то разнобой знатный, так что
> соваться прописывать какие-нибудь ограничения вызовов через seccomp без системд рискнет
> не каждый первый. А когда это директива в конфигах - почему
> бы и нет?Никто не говорит, что до systemd все было идеально. Но systemd пытается спрятать проблемы, а не решить их.
> Ну то-есть вы же понимаете что я не могу
> убить на кодинг запускалки столько же времени сколько на кодинг сервисов,
> ради которых все затевается, правда?Все же вы существенно преувеличиваете. В большинстве случаев достаточно одной-двух строк.
> Поэтому на практике все придет к
> халтуре, джамшутингу и бустанию всех мыслимых фич, в ущерб всему. Большинство
> инит скриптов это отлично иллюстрируют.Фактически systemd просто спрятал то, что было в скриптах.
> Без systemd по моему опыту большинство виденых линуксных систем как-то так по
> жизни вообще кладет на всякое там обслуживание вачдога. И при зависоне
> - требует живого юзверга, жмущего резет или передергивающего питальник. А когда
> этого юзера нет... эм... получается не комильфо.ИМХО вачдог не понацея, а крайнее средство. Если произошло зависание, то нужно искать и устранять причину, а не тупо перезагружать. Для некоторых ситуаций, когда лучше глючная, но хоть как-то работающая система, это может сработать. Например самолетах, системах жизнеобеспечения или как подстраховка для всякой автоматики.
Но для ПК смысла мало - ядро например по-умолчанию даже в ребут само не уходит при kernel panic. С сервисами/драйверами еще менее однозначно - зависла видеокарта наглухо, по идее нужен ребут. Но если на фоне рендеринг 20 часов шел? Или основная задача этой машины - сервер и видеокартой там пользуются раз в неделю. ИМХО правильно все делают - вачдог по-умолчанию не нужен, а кому он реально нужен - разберется и настроит.
> Ну вон в openwrt
> например, обслуга вачдога, конечно, есть. Но если встанет колом какой-то важный
> для работы железки сервис - традиционно будут опаньки. И все эти
> runit, monit и прочая прекрасно. Только слегка не то. Скажем, сервис
> может и не быть сетевым в плане доступности портов на listen.Если железо нормальное, то вероятность такого расклада (зависание сервиса без segfault) очень мала.
Если железо с глюками - его менять нужно, а не ждать когда оно полностью встанет. Особенно забавно, когда люди говорят: винт глючит, что делать? Отвечаю: срочный бэкап всего нужного на новый винт. Через пару дней: винт глючить перестал, новый покупать пока не буду. Через неделю - винт полностью обрубился, бэкапов нет ...
> И вообще, довольно так себе критерий живости программы. Ну вот скажем
> поливалка цветов, щелкающая релюхами по таймеру. Тот кто щелкает релюхой -
> не обязан быть сетевым сервисом. И даже если оно управляется через
> веб, это совсем не значит что я хочу иметь дело с
> сетью в именно той проге, которая релюхой клац-клац. А вот
> если прога повиснет - клац-клац релюхой сорвется. FAIL.А если реле залипнет ? ;) Тут однозначно управление реле (а лучше симистором/мосфитом) на МК, а все не критичное на ПК/RBPi/etc. И программу можно сделать bug free практически сразу и вачдог на случай аппаратного зависания есть.
> Ну да. Я видел пару уродцев, типа пальмоси, где все пытались совать
> в БД, чтоли. Ну их таких! При работе с такой системой
> возникает ощущение что мне оторвали руки и ноги, поэтому печатать на
> клавиатуре теперь можно исключительно носом. Результативность взаимодействия с системой
> - на таком уровне. ФС как таковая и есть БД. Только
> простая и низковровневая, так что покрывает все мыслимые юзкейсы а не
> пытается с пеной у рта доказать что "да и фиг с
> ним, с открытием аттача из почты другой программой".У меня подобное ощущение и результативность от некоторых "облачных" технологий возникает.
> Но для ПК смысла мало - ядро например по-умолчанию даже в ребут
> само не уходит при kernel panic. С сервисами/драйверами еще менее однозначно
> - зависла видеокарта наглухо, по идее нужен ребут. Но если на
> фоне рендеринг 20 часов шел? Или основная задача этой машины -
> сервер и видеокартой там пользуются раз в неделю. ИМХО правильно все
> делают - вачдог по-умолчанию не нужен, а кому он реально нужен
> - разберется и настроит.Вот именно, кому он реально нужен -- используют, например, monit (который стал доступен ещё задолго до появления systemd).
> Вот именно, кому он реально нужен -- используют monit ещё задолго до
> существования systemd.А как ваш monit поможет вачдоговать процесс который клацает релюшкой? У этого процесса нет сетевой конективити. Автор системд в курсе что всякие дурные требования такого плана не комильфо. Поэтому у него есть некое апи. Это апи простое и более-менее похоже на обычную логику работы обычного вачдога, привычную всем микроконтроллерщикам и прочим "close to metal" системщикам. Это логично, хорошо и правильно. И легко привинчивается. Чему я несказанно рад. Особенно когда процесс куда сложнее клаца релюшкой, но тоже не делает с сетью чуть менее чем нифига. А ваш маразм меня уже несколько достал. Ну что за феерическе бакланы с горбатыми решениями, которые однако на все случаи жизни Мнение Имеют? "Зато не системд!!!111". Вот это я понимаю - хейтерство в хучшем виде.
>[оверквотинг удален]
> процесса нет сетевой конективити. Автор системд в курсе что всякие дурные
> требования такого плана не комильфо. Поэтому у него есть некое апи.
> Это апи простое и более-менее похоже на обычную логику работы обычного
> вачдога, привычную всем микроконтроллерщикам и прочим "close to metal" системщикам. Это
> логично, хорошо и правильно. И легко привинчивается. Чему я несказанно рад.
> Особенно когда процесс куда сложнее клаца релюшкой, но тоже не делает
> с сетью чуть менее чем нифига. А ваш маразм меня уже
> несколько достал.В чём конкретно проблема "вачдоговать" процесс, который "клацает релюшкой"? И чего конкретно делает systemd в данной ситуации?
Лично у меня "клацают релюшками" вообще отдельные ATmega и STM32, и я пока не понимаю о чём речь.
> Ну что за феерическе бакланы с горбатыми решениями, которые
> однако на все случаи жизни Мнение Имеют? "Зато не системд!!!111". Вот
> это я понимаю - хейтерство в хучшем виде.Systemd-lover-ы почему-то первыми переходят на личности. Не умеете говорить как взрослые люди?
>> Ну что за феерическе бакланы с горбатыми решениями, которые
>> однако на все случаи жизни Мнение Имеют? "Зато не системд!!!111". Вот
>> это я понимаю - хейтерство в хучшем виде.
> Systemd-lover-ы почему-то первыми переходят на личности. Не умеете говорить как взрослые
> люди?P.S.: И было бы хейтерством, если я был бы против существования и развития systemd. Но это не так. Я считаю, что в идеале всё должно быть about choice, и я рад когда в копилке СПО появляются дополнительный развитый проект. Однако я против форсирования и lock-in-ов. И если мне форсируют systemd (и пытаются завязать на него всё подряд и тем самым лишить меня этого «about choice»), то тогда я уже начинаю высказывать своё мнение по поводу того, насколько он мне подходит или не подходит. В ответ каждый раз слышу оскорбления, в то время как я сам обычно вежлив.
> В чём конкретно проблема "вачдоговать" процесс, который "клацает релюшкой"?В том что это - не сетевой процесс. А вот его живость - таки роялит. В смысле, если такой процесс сдох - железка перестала выполнять свою миссию. И далее уже никому не интересно насколько там было живым ядро и что там еще.
> И чего конкретно делает systemd в данной ситуации?
Вывешивает нормальное апи вачдога для процессов и далее мониторит живость процессов. А живость самого системд мониторится железным вачдогом. Очень логичное решение.
> Лично у меня "клацают релюшками" вообще отдельные ATmega и STM32,
Это все круто, но если у меня уже есть большой апликушный проц, допустим, "потому что надо лопатить ...цать мегабайтов данных" ну или там "работать с "взрослой" периферией", а требования к реалтайму отсутствуют - ставить лишнюю мегу для клацания релюшкой как-то не того. А ты попробуй на STM32 картинку с usb-камеры получить и записать ее на sata HDD, например?
> и я пока не понимаю о чём речь.
О том что случаи бывают разные. А у поттеринга есть неплохое апи вачдога. Который именно вачдог, примерно так как его и понимают микроконтроллерщики и системщики. И если дернуть вызов апи в паре характерных мест мне не в напряг, то выписывать какую-то там работу с сетью в сервисе, клацавшем релюхой мне даром не упало.
> Systemd-lover-ы почему-то первыми переходят на личности.
А какой конкретной личности там досталось? Это общее описание ситуации в целом было, как я это вижу.
> Не умеете говорить как взрослые люди?
Ну что вы, взрослые тут только анти-системд-нытики, предлагающие писать программы совсем без ошибок, допаивать дополнительные uC, что там еще.
>> Но для ПК смысла мало - ядро например по-умолчанию даже в ребут
>> само не уходит при kernel panic. С сервисами/драйверами еще менее однозначно
>> - зависла видеокарта наглухо, по идее нужен ребут. Но если на
>> фоне рендеринг 20 часов шел? Или основная задача этой машины -
>> сервер и видеокартой там пользуются раз в неделю. ИМХО правильно все
>> делают - вачдог по-умолчанию не нужен, а кому он реально нужен
>> - разберется и настроит.
> Вот именно, кому он реально нужен -- используют, например, monit (который стал
> доступен ещё задолго до появления systemd).Перепрочитал, и понял, что может быть неверно интерпретировано. Тут речь была про userspace. Если нужен watchdog для ядра или hardware, то проще всего использовать обычный аппаратный watchdog. И действительно его нужно включать только тогда, когда он действительно нужен. И ничего сложного в его настройке нет… Совершенно не понятно зачем тут systemd.
> Совершенно не понятно зачем тут systemd.Потому что чукча не читатель, чукча писатель?
Системд - вывешивает апи вачдога, для всех желающих процессов. И далее вачдогит их. А живость самого системд - вачдогит аппаратный вачдог. Весьма логичная конструкция получается.
А сказки про то что программы надо писать без багов и они не должны виснуть - это отлично. Но - не про эту планету. И это именно вачдог. А не какая-то там проверка живости по сети и прочая (кто сказал что меня может интересовать только живость сетевых программ?).
>> синонимом понятий "геморрой" и "много долботни на ровном месте".
> Это если systemd умеет делать то, что нужно.А если даже и не умеет - ВНЕЗАПНО, из него можно позвать скрипт. Только это будет надо весьма редко.
> А вот внедрить в него то, чего он не умеет, будет на порядок сложнее,
Поэтому кульсисоп среднего пошиба может как и раньше набросать скрипт, если иначе слвсем никак. Только вот т.к. админть это сложнее - это должно быть last resort. Стремный гомнокод вообще лишний раз в систему лучше не пихать. А инит скрипты чаще всего заслуживают именно такой эпитет почему-то.
> чем в простую инит систему.
Туда отродясь никто никаких фич не запиливал. Инит не умеет чуть менее чем нифига.
> Пример того как у меня работает сеть на ноуте я приводил ранее:
> http://www.opennet.me/openforum/vsluhforumID3/100356.html#434А еще там пример гениально ... гунявого управления сервисами, в хучших традициях скрипткидей. С while true. Подумайте что будет с этим однострочником, если сервис фатально издох. Подсказываю: скоростной рестарт в цикле тяжелого сервиса может вклинить всю систему. Знаете как здорово, когда система радостно рестартует тяжеленный сервис на скорость, а менеджмент интерфейсы при этом клинит? Вот чтобы такое у...ство раз и навсегда развидеть - появились апстарт и системд. Где это сделано нормально. Без левых допущений, халтуры и упрощений! Мне так больше нравится чем ваш IT-джамшутинг. Работает потом лучше.
> Не уверен, что это легко получится реализовать через systemd и не получить
> различных косяков в совершенно неожиданных местах.Продвинутые сетевые конфигурации через системд делать довольно странно. С другой стороны, у меня network manager вон живет и ему systemd жить не мешает...
> Но systemd пытается спрятать проблемы, а не решить их.
Я почему-то вижу скриптокидозниов рассказывающих мне про то что фичи "не требуются". И Поттера, запиливающего фичи, вместо левых сказок. Как мне больше нравится - догадайтесь :)
> Все же вы существенно преувеличиваете. В большинстве случаев достаточно одной-двух строк.
Я видел как такой трэш потом работает. "А потом мы подумаем что будет с системой, если у тяжелого сервиса побились рантайм данные и он не взлетает". После того как пяток админов хорошенько обложит "кoзла" "матами".
Вот в апстарте и системд это сделано нормально. А на вашем велике из водопроводных труб вы сами и рассекайте, имхо.
> Фактически systemd просто спрятал то, что было в скриптах.
Сначала апстарт. И да, они это сделали по людски, без кучи дурных грабель в очевидных местах. А потом и системд. Они еще и доразвили идею. Для каких-то совсем хитрых случаев может и не хватит фич. Ну вот тогда я и буду и звать скрипты.
> ИМХО вачдог не понацея, а крайнее средство.
Ну разумеется. Только юзер прущий в тутуево чтобы передернуть питальник или нажать ресет - еще более крайнее.
> Если произошло зависание, то нужно искать и устранять причину, а не тупо перезагружать.
Если зависание случается раз в год - может быть напряжно год караулить баг, кукуя целый год в тутуево. Еще интереснее узнать что на самом деле это какая-нибудь космическая частица битик в памяти перевернула. А вот кадр которому придется двигать в тутуево чтобы нажать ресет - выскажет нелестные эпитеты. И будет по своему прав.
> или как подстраховка для всякой автоматики.
Ну да. На обычном десктопе юзер и сам ресет нажать может. Но мир не кончается на десктопах. На серверах ресет жать уже напряжно. Особенно тем у кого их 1000 штук распихано. А в эмбедовке, до которой добираться может быть дольше и дороже - тем паче. И линух, вы только подумайте, активно применяется на серверах и в эмбедовке. Да и на десктопе я не откажусь от человеческого прописывания параметров запуска процессов, руления контейнерами и прочая.
> само не уходит при kernel panic.
(думаю вы догадываетесь с какими дефолтами я билданул армовское ядро)
> С сервисами/драйверами еще менее однозначно
У меня логика простая: система или делает то что должна, или уходит в ребут и восстанавливается в известное, работоспсобное и безглючное состояние. Работу в глючном режиме или длительный клин - считаю неприемлимыми вариантами в имеющихся задачах. Если система совсем умерла - человек еснно требуется, как и анализ причин "а чего это оно". Но знаете, даже дубовые электрики, с незапамятных времен просекли что до того как посылать бригаду к черту на рога, есть смысл попробовать пару раз попытаться перезапустить линию на автомате. Компьютеры, конечно, иное. Но сам по себе инженерный принцип, имхо, имеет право на жизнь. Потому что у компьютеров сбои тоже делятся на "transient" и "permanent". Да-да, любой разработчик и QA в курсе что бывают баги/сбои которые вы видите 1 раз в своей жизни. Сказки про то что их быть не должно - круто, но - не про эту планету.
> делают - вачдог по-умолчанию не нужен, а кому он реально нужен
> - разберется и настроит.Вроде как ядро нынче таки врубает железный вачдог, если он есть. Но сработает он только если умерло ядро. А системд ессно не вачдогит процессы по дефолту, пока не попросили явно. Тем более что это надо код дергающий апи системд в процесс дописать, как и в случае с вачдогом в прошивке. Зато если оно потребовалось - не надо писать логику этого самого вачдога самому.
> Если железо нормальное, то вероятность такого расклада (зависание сервиса без segfault)
> очень мала.А я вот видал и "зависания без segfault" тех или иных программ, поэтому ваши аргументы для меня звучат как отмазка. А с практической точки зрения:
- Дописать пяток строк в конфиг и капельку кода - не выглядит высокой ценой за уменьшение предъяв.
- А вот самому писать ВСЮ логику вачдога-супервизора уже как-то явно перебор получается.> Если железо с глюками - его менять нужно, а не ждать когда оно полностью встанет.
Идите, расскажите электрикам что они должы выбегать всей бригадой на любое отключение линии, а автоматический перезапуск - никак не можно. А электрики популярно и доступно расскажут вам что они думают о перспективе бегать к черту на рога в пять раз чаще... ;)
> дней: винт глючить перестал, новый покупать пока не буду. Через
> неделю - винт полностью обрубился, бэкапов нет ...Случаи разумеется бывают разные. Но в эмбедовке например обычно флеш-память. У него failure rate конечно не ноль. Но он относительно предказуем в плане поведения. Не говоря о том что ему обычно жизнь пытаются продлить до состояния когда лимитом будет гарантированное время хранения данных из даташита на чип, а не что-нибудь еще. Ну и никто в здравом уме не гарантирует вечной жизни своих устройств, если что.
> А если реле залипнет ? ;)
Ну, знаете, если производитель гарантировал 200 000 срабарываний, которых хватит на следующие 100 лет - я ему и переадресую претензии. Ну и на будущее не буду иметь дело с таким брендом, если такое регулярно будет случаться.
> Тут однозначно управление реле (а лучше симистором/мосфитом) на МК,
> а все не критичное на ПК/RBPi/etc.Т.к. все это совершенно не критично к скорости, а передерг питания "Pi" крайне нежелательное событие, мк - лишний элемент системы. Дернуть GPIO может и Pi-образный девайс, если требований к скорости нет. При том в системе меньше компонентов, следовательно она надежнее. В конце концов, мк тоже может умереть. Любители атмелок с тиражами вам расскажут. И про нулевые ячейки еепрома и про слет флеша :)
> И программу можно сделать bug free практически сразу и вачдог на случай аппаратного
> зависания есть.Так у моих ARMовых борд он тоже есть. Да что там, у ноута и десктопов - и то в чипе SuperIO нынче вачдог до кучи встроен.
> У меня подобное ощущение и результативность от некоторых "облачных" технологий
Мне они тоже не очень нравятся. Я не фанат вендорлока.
>> А вот внедрить в него то, чего он не умеет, будет на порядок сложнее,
> Поэтому кульсисоп среднего пошиба может как и раньше набросать скрипт, если иначе
> слвсем никак.Речь о том, что при внедрении своих скриптов, нужно быть точно уверенным, что systemd не вмешается в их работу. Для этого нужно знать всю внутреннюю логику работы systemd, а это не 15 строк скрипта.
>> чем в простую инит систему.
> Туда отродясь никто никаких фич не запиливал. Инит не умеет чуть менее
> чем нифига.В этом и смысл - что их можно безболезненно править и не боятся, что они будут вмешиваться в работу друг друга.
>> Пример того как у меня работает сеть на ноуте я приводил ранее:
>> http://www.opennet.me/openforum/vsluhforumID3/100356.html#434
> А еще там пример гениально ... гунявого управления сервисами, в хучших традициях
> скрипткидей. С while true. Подумайте что будет с этим однострочником, если
> сервис фатально издох. Подсказываю: скоростной рестарт в цикле тяжелого сервиса может
> вклинить всю систему. Знаете как здорово, когда система радостно рестартует тяжеленный
> сервис на скорость, а менеджмент интерфейсы при этом клинит? Вот чтобы
> такое у...ство раз и навсегда развидеть - появились апстарт и системд.
> Где это сделано нормально. Без левых допущений, халтуры и упрощений! Мне
> так больше нравится чем ваш IT-джамшутинг. Работает потом лучше.Я с вами как с компетентным человеком разговариваю - а вы просто в душу ...
Я и так там написал - "Сообщение в логи/на email/sms добавить по вкусу :)"
Я должен был написать как для полного идиота - вставьте задержку/максимальное количество итераций?>> Не уверен, что это легко получится реализовать через systemd и не получить
>> различных косяков в совершенно неожиданных местах.
> Продвинутые сетевые конфигурации через системд делать довольно странно.Ну вот и приплыли: а чем он вообще занимается, если даже нельзя полноценно расписать реакцию при изменении состояния железа? Зачем он тогда в себя udev втянул?
>> Но systemd пытается спрятать проблемы, а не решить их.
> Я почему-то вижу скриптокидозниов рассказывающих мне про то что фичи "не требуются".ИМХО фичи должны быть отдельными простыми программами, слабо зависящими от конкретной системы инициализации.
>> Все же вы существенно преувеличиваете. В большинстве случаев достаточно одной-двух строк.
> Я видел как такой трэш потом работает. "А потом мы подумаем что
> будет с системой, если у тяжелого сервиса побились рантайм данные и
> он не взлетает". После того как пяток админов хорошенько обложит "кoзла"
> "матами".Что мне нужно сделать в systemd для получения эквивалента "nc -ll -p 7777 -e /usr/libexec/sftp-server &"? Это будет проще, понятнее, надежнее?
Приведите выщ реальный пример запука сервиса и требования, и посмотрим насколько сложно для него написать запуск.
> У меня логика простая: система или делает то что должна, или уходит
> в ребут и восстанавливается в известное, работоспсобное и безглючное состояние. Работу
> в глючном режиме или длительный клин - считаю неприемлимыми вариантами в
> имеющихся задачах.Ну и толку - сдохла видюха на сервере, получим бесконечный ребут, без возможности удаленно зайти на машину.
> Если система совсем умерла - человек еснно требуется, как
> и анализ причин "а чего это оно". Но знаете, даже дубовые
> электрики, с незапамятных времен просекли что до того как посылать бригаду
> к черту на рога, есть смысл попробовать пару раз попытаться перезапустить
> линию на автомате.А то вдруг пьяного мужика, подключавшего сварку к 10KB еще не добило или заклинивший движок только начал перегреваться и еще не сгорел ...
> Компьютеры, конечно, иное. Но сам по себе инженерный
> принцип, имхо, имеет право на жизнь. Потому что у компьютеров сбои
> тоже делятся на "transient" и "permanent". Да-да, любой разработчик и QA
> в курсе что бывают баги/сбои которые вы видите 1 раз в
> своей жизни. Сказки про то что их быть не должно -
> круто, но - не про эту планету.Согласен, но выводы совершенно иные - во многих ситуациях тупой перезапуск через вачдог может сделать еще хуже. Если уж серьезно относится к безотказности - то я бы сделал отдельный девайс для ресета, который ждет sms/email с паролем.
>> Если железо нормальное, то вероятность такого расклада (зависание сервиса без segfault)
>> очень мала.
> А я вот видал и "зависания без segfault" тех или иных программ,
> поэтому ваши аргументы для меня звучат как отмазка.Естественно они есть, но причем здесь вачдог? Вачдог нужен когда железо/драйвер шалит, дабы обнулить состояние всех регистров и стартануть все с нуля.
Если завис просто софт - killall его (рестарт по вкусу), а остальные сервисы/приложения должны продолжать работать.
> Т.к. все это совершенно не критично к скорости, а передерг питания "Pi"
> крайне нежелательное событие, мк - лишний элемент системы. Дернуть GPIO может
> и Pi-образный девайс, если требований к скорости нет. При том в
> системе меньше компонентов, следовательно она надежнее.Pi-образный девайс на два порядка сложнее МК, соответственно вероятность отказа на два (а может и более) порядка выше.
> В конце концов, мк тоже
> может умереть. Любители атмелок с тиражами вам расскажут. И про нулевые
> ячейки еепрома и про слет флеша :)Для особо критичных задач МК можно продублировать - на цене это особо не скажется.
Да и пока в своей практике я не видел зависшего МК, хотя многие работают 24/7. Чего не скажешь про ПК/роутеры/3g модемы/карты памяти.
Был случай когда непомерные EMI в системе зажигания приводили к перезапуску, так движок даже заглохнуть не успевал между перезагрузками МК :)
>> И программу можно сделать bug free практически сразу и вачдог на случай аппаратного
>> зависания есть.
> Так у моих ARMовых борд он тоже есть. Да что там, у
> ноута и десктопов - и то в чипе SuperIO нынче вачдог
> до кучи встроен.Да но гарантировать bug free всего программного комплекса на RBPi/ПК невозможно, в отличии от МК.
> что systemd не вмешается в их работу.Systemd - не искусственный интеллект. Ничего особенного со скриптами он не делает.
> Для этого нужно знать всю внутреннюю логику работы systemd, а это не 15 строк скрипта.
До того как пользоваться фичами системд - придется почитать мануал на все это. А в случае с sysv скриптами - там есть некий слой compatibility. Идея, как я понимаю, в том чтобы оно работало без изменений в скриптах или с минимумом таковых. Я правда sysv скрипты понятно где вертел и сильно это не смотрел.
А если вы из системд вызвали какой-нибудь sh - он и в африке sh. И выполнит ваш скрипт, "как обычно". Системд может вмешиваться разве что по поводу всяких там таймаутов старта/стопа и прочих лимитов на время работы. Если они есть. Ксати да, скриптеры на все это кладут. И если сервис повис на старте - "while true" не спасет. И вот такое - куда ни ткни.
А еще, если вы про экономию ресурсов - интерпретер шелла, висящий на каждый while true - ресурсов кушает. Поболее чем systemd на отслеживание процесса.
> В этом и смысл - что их можно безболезненно править и не
> боятся, что они будут вмешиваться в работу друг друга.1) Насчет безболезненности... когда оно потом не взлетит "почему-то", а в логах ноль, а на коды возврата и прочие сообщения в stderr все забили - знаете, я без такого "счастья" у себя в системах обойдусь.
2) Насчет вмешательства - когда это вмешательство становится нужно, фича резко превращается в баг. Скрипты живут своими жизнями. Сами по себе, помимо администратора. А потом, через пару лет, начинается удивление: блин, откуда это взлетает? И по каким же блин критериям? Особенно весело если это сервер который кто-то кому-то передает на администрирование - новый админ 100% мечтал потратить недельку на разгадывание ребусов.
> Я с вами как с компетентным человеком разговариваю - а вы просто в душу ...
Уж простите что я назвал вещи своими именами, я так привык. Вещицы типа while true - хороши чтобы ими на форуме махать. Но с ними наешься "счастья" на автопилотных девайсах, серваках и прочих подобных применениях. Можно узнать много нового об ассортименте ошибок, сбоях и всех мыслимых и немыслимых вариантах как это может произойти. Вот штуки типа системд - писаны с учетом накопленного опыта факапов. И учитывают множество характерных грабель. В отличие от. И все это легко перенастраивается соотв. параметрами.
> Я и так там написал - "Сообщение в логи/на email/sms добавить по вкусу :)"
А "джамшутинг" оно не потому. А т.к. не мониторит полдюжины иных возможных failure modes и проблемных ситуаций. А они - возможны и случаются. И если самому это все кодить в скриптоте - получится жуткий макаронный монстр.
> вставьте задержку/максимальное количество итераций?
А также мониторинг таймаутов старта и стопа, придумайте свое уникальное апи для проверки живости сервиса, напишите обработку всех мыслимых ошибок, редиректы stdin-out-err... ну в общем - перепишите половину системды на соплях и скотче.
> Ну вот и приплыли: а чем он вообще занимается, если даже нельзя полноценно
> расписать реакцию при изменении состояния железа?Он - это кто? Системд или удав? Они в принципе занимаются относительно разными вещами. Персекающимися лишь местами. Всякие сетевые вещи там запилены по минимуму. Видимо на случай когда штуки типа dhcp таки нужны, а переть что-то большое не хочется.
> Зачем он тогда в себя udev втянул?
Вообще, это 2 разные программы. Но udev таки может сигналить системде про всякие изменения железа. Поэтому насчет того что там нельзя расписать - наверное, можно. Но я не очень копался в том как удав и системд перекидываются такой информацией, мне это не требовалось как-то.
> ИМХО фичи должны быть отдельными простыми программами, слабо зависящими от конкретной
> системы инициализации.А я хочу видеть, грубо говоря, код который сделает форк и поставит процессу запрошенные параметры. Желательно по более-менее единообразным настройкам и без долботни. А колупаться с 20 разных программ от разных авторов для всего лишь запуска сервиса - утомительно. А еще и ввинтить 20 обработок и логинга ошибок... имхо, вы так без меня развлекайтесь.
> Что мне нужно сделать в systemd для получения эквивалента "nc -ll -p
> 7777 -e /usr/libexec/sftp-server &"? Это будет проще, понятнее, надежнее?Если у вас уже есть готовый командлайн, можно его взять да и вписать в системдшный юнит. И да, всякие & намекают на лишний фак мозга с атачем-детачем stdin/out. А знаете, у поцтера это все как-то удобно сделано. Даже всякие извращения с форком - не требуются. И настраиваемо куда и что. И по дефолту, и оверрайд по юнитам можно.
> Приведите выщ реальный пример запука сервиса и требования, и посмотрим насколько сложно
> для него написать запуск.А смысл? Вы будете выписывать мне логинг и анализ кодов возврата? Всех вызываемых команд? Рестарт сервисов? Человеческий трекинг что и откуда взялось? Таймауты? Переназначение stdin/out/err? Посмотрите man systemd.exec, systemd.unit и systemd.service (они есть и онлайн) и подумайте что я так или иначе желаю половину этих опций в разных ситуациях. Вы правда разопретесь кодить такой макаронный монстр на скриптах? И даже почему-то думаете, что я захочу копаться в этом спагетти? Вместо того чтобы аккуратно прописать несколько параметров в конфиге? А если мне фич не хватит - вот тогда я позову скрипт. А хоть и из системды. К тому же systemd покажет - "откуда эта фигня запустилась". В sysv init это вообще не решаемо для ситуации с двойным форком. А в вот через cgroups - вполне.
Я, конечно, ценю такую дружественность от человека показавшего мне udev (он оказался любопытной штукой). Но, блин, не буду же я вас вызывать на каждый сервис который мне куда-то надо запилить. Да и мое удобство прописать несколько строк в конфиг не изменится.
> Ну и толку - сдохла видюха на сервере, получим бесконечный ребут,
Это какой-то совсем сферический юзкейс в вакууме. Для начала, в обычные сервера (и эмбедовку) нынче обычно не ставят дискретные видеокарты - 2015 год на дворе. А если сдох проц/чипсет/SoC - таки приплыли. Потребуется человек, который сменит железку.
> без возможности удаленно зайти на машину.
Это почему? Что за синтетическая ситуация? Не говоря о том что там где мне это интереснее всего - никаких "видеокарт" нет: 2015 год на дворе, дяденька. Бывают всякие нишевые юзкейсы, типа складов забитых GPU как у майнеров *коинов. Но это отдельный разговор и у них тоже таких проблем не наблюдалось, дискретный GPU обычно клинится сам и на этом все заканчивается. Сервер крутится без графики и поэтому клин 1 из GPU всем пофигу.
> или заклинивший движок только начал перегреваться и еще не сгорел ...
Autorecloser'у пофиг. Он попробует перезапустить линию в допущении что, возможно, это transient. Чаще всего так и оказывается. По поводу чего autorecloser'ы и применяют. Мало кто хочет разыскивать испарившийся дрист птички на изолятор или сгоревшую ветку, тратя на это время бригады.
> тyпой перезапуск через вачдог может сделать еще хуже.
Я обычно затачиваю железки под автопилот так, что они выходят на режим после подачи питания, не требуя внимания. Совсем. Аппаратный ресет - то же что и переподача питания. Железка должна штатно выйти на режим. Если это не так, я где-то облажался и это мой баг системной интеграции. Разрушение ФС? Можно держать rootfs readonly в большинстве случаев, или минимизировать записи (флеш к тому же запись не любит). А runtime данные хранить в tmpfs/zram/.... - требования к их non-volatile'ности, потерям и прочему весьма дико варьируются.
> Если уж серьезно относится к безотказности - то я бы сделал отдельный
> девайс для ресета, который ждет sms/email с паролем.А кто будет проверять проверяющего? И вас не смущает, что сотовый модем - это еще несколько мегов черти-какого кода, сложный протокол, целая ОС в симкарте, и в общем то не очень надежная сеть? Не говоря о том что сотовый модем ощутимо удорожает и усложняет конструкцию. Надежность такой сбрасывалки будет врядли выше надежности вачдога. И будет много иных факторов. Ну там сотовый модем. Его ОС и вачдоги. И насколько он там выкручивается из разных ситуаций.. нуу... вот вы как раз на себе и протестируете ;].
>> поэтому ваши аргументы для меня звучат как отмазка.
> Естественно они есть, но причем здесь вачдог? Вачдог нужен когда железо/драйвер шалит,Вачдог нужен для восстановления работы сбойнувшей системы в ожидаемое состояние, за разумное время, без внешний воздействий. Причин по которым система может сбойнуть - много. И многие из них - transient.
> дабы обнулить состояние всех регистров и стартануть все с нуля.
В общем случае вачдог обеспечивает восстановление после transient сбоев. Нечто типа autorecloser'а у электриков.
> Если завис просто софт - killall его (рестарт по вкусу), а остальные
> сервисы/приложения должны продолжать работать.Вы знаете, задачи разные бывают. И кто и что кому там должен - очень варьируется. Можете посмотреть на mission control entity в N900 и сотоварищи как пример того как и что бывает. Когда девайс ребутается при отвале критичных компонентов, чтобы не вышло так что юзер два дня про...вал звонки из-за глюков.
> Pi-образный девайс на два порядка сложнее МК,
А связка Pi-образный + МК будет еще сложнее чем каждый по отдельности. А основы теории надежности говорят нам что так будет еще менее надежно.
> соответственно вероятность отказа на два (а может и более) порядка выше.
А с практической точки зрения - железяки показывают вполне приличную надежность.
> Для особо критичных задач МК можно продублировать - на цене это особо не скажется.
Дублируйте наздоровье. Вот только сколько МК не дублируй, а например картинку с usb-камеры на хард микроконтроллером не запишешь. А юзер врядли будет рад узнать что девайс оказывается уже 2 дня груши околачивает и ничего не наблюдает. Случаи разные бывают. И вы с вашими попытками серебряные пули втюхивать - смотритесь от "странно" до "глупо", имхо. У мк есть вполне характерные лимиты что они могут. И они ни разу не замена большим апликушным процам. А вот спихнуть часть МК-подобных операций на более крупный проц иногда можно. Если реалтаймность не жмет, апликушник всяко нужен, etc.
> Да и пока в своей практике я не видел зависшего МК, хотя
> многие работают 24/7. Чего не скажешь про ПК/роутеры/3g модемы/карты памяти.А я могу отметить что ARMовские железяки при правильном подходе показывают неплохую надежность. Достаточную для многих применений.
ПК - сложная штука с кучей софта всех мастей и двумя газилионами процов кроме системного. Малопредсказуемы. Роутеры - там порой или нет вачдога, или китайцы его просто не включили, т.к. не умеют обслуживать. На то и китайцы. Или питальник разведен по китайски и из китайских чипов. И при заскоках питания уходит в возбуд и кормит проц таким трэшом, что проц без шансов. 3g modem - там реалтайм операционка на несколько метров, пара ядер проца минимум, а то и 4 разных проца. И еще сим-карта. Которая проц с отдельной памятью, ос, кучей приложений и даже простой ФС. Так что сказ про смс уведомления... эээ... знаете, уведомлялка или сбрасывалка по смс - менее надежна чем обороняемый ей девайс :)
> движок даже заглохнуть не успевал между перезагрузками МК :)
Ну так я не собираюсь делать систему зажигания на апликушном проце. Там наверное приличные требования к реалтайму, а сильно много мозгов как у апликушника - куда их там?
> Да но гарантировать bug free всего программного комплекса на RBPi/ПК невозможно, в
> отличии от МК.Я вижу некое отличие между pi-like и писюком. В одноплатнике может быть 1 проц, без проприетарного кода (кроме может быть минимального boot rom, тривиального в анализе и логике работы). Это достаточно предсказуемая связка, где я контролирую все. Куда предскауемее писюшника с его BIOS, SMM и прочим крапом.
>> что systemd не вмешается в их работу.
> Systemd - не искусственный интеллект. Ничего особенного со скриптами он не делает.Не надо быть искусственным интеллектом, чтобы вмешиваться в работу. Он может выставлять свои переменные окружения, cgroup-ы и прочие вещи, что может влиять на работу запускаемых приложений. Например один демон, который я писал, сам для себя выставляет cgroup, seccomp и прочее.
[offtop]Я вот пару дней назад столкнулся с очередной проблемой pulseaudio, который отказывался работать из-за неверно выставленной переменной DISPLAY. В качестве ошибки сообщал просто "Connection refused". Диагностировалось через strace. В общем, очередной привет от Леннарта.[/offtop]
>[оверквотинг удален]
> это. А в случае с sysv скриптами - там есть некий
> слой compatibility. Идея, как я понимаю, в том чтобы оно работало
> без изменений в скриптах или с минимумом таковых. Я правда sysv
> скрипты понятно где вертел и сильно это не смотрел.
> А если вы из системд вызвали какой-нибудь sh - он и в
> африке sh. И выполнит ваш скрипт, "как обычно". Системд может вмешиваться
> разве что по поводу всяких там таймаутов старта/стопа и прочих лимитов
> на время работы. Если они есть. Ксати да, скриптеры на все
> это кладут. И если сервис повис на старте - "while true"
> не спасет. И вот такое - куда ни ткни.Чем OpenRC не устраивет?
> А еще, если вы про экономию ресурсов - интерпретер шелла, висящий на
> каждый while true - ресурсов кушает. Поболее чем systemd на отслеживание
> процесса.И даже какой-то supervisor туда тоже впиливали. Хотя ниразу им не пользовалсяс.
> 2) Насчет вмешательства - когда это вмешательство становится нужно, фича резко превращается
> в баг. Скрипты живут своими жизнями. Сами по себе, помимо администратора.
> А потом, через пару лет, начинается удивление: блин, откуда это взлетает?
> И по каким же блин критериям? Особенно весело если это сервер
> который кто-то кому-то передает на администрирование - новый админ 100% мечтал
> потратить недельку на разгадывание ребусов.Какое удивление? О чём речь? Ниразу при передаче/получении сервера у меня не было таких проблем.
Если же админ криворукий то никакие "правильные инструменты" не помогут защитить сервер от тонны нечитаемых костылей.
>> Зачем он тогда в себя udev втянул?
> Вообще, это 2 разные программы. Но udev таки может сигналить системде про
> всякие изменения железа. Поэтому насчет того что там нельзя расписать -
> наверное, можно. Но я не очень копался в том как удав
> и системд перекидываются такой информацией, мне это не требовалось как-то.Тем ни менее насколько сложно будет пользоваться systemd, если заменить udev наместо mdev?
>> ИМХО фичи должны быть отдельными простыми программами, слабо зависящими от конкретной
>> системы инициализации.
> А я хочу видеть, грубо говоря, код который сделает форк и поставит
> процессу запрошенные параметры. Желательно по более-менее единообразным настройкам и
> без долботни. А колупаться с 20 разных программ от разных авторов
> для всего лишь запуска сервиса - утомительно. А еще и ввинтить
> 20 обработок и логинга ошибок... имхо, вы так без меня развлекайтесь.openrc-шные скрипты минимальны по своему размеру.
А вот я хотел бы видеть рабочую систему в контейнерах с произвольными настройками. А когда внезапно systemd с journald отказывались работать из-за специфичной настройки контейнера -- это был очень неприятный момент. Слишком монструозные вещи, чтобы выполнять слишком простые задачи. Да, уже исправили, но было неприятно.
>> Ну и толку - сдохла видюха на сервере, получим бесконечный ребут,
> Это какой-то совсем сферический юзкейс в вакууме. Для начала, в обычные сервера
> (и эмбедовку) нынче обычно не ставят дискретные видеокарты - 2015 год
> на дворе. А если сдох проц/чипсет/SoC - таки приплыли. Потребуется человек,
> который сменит железку.Хоть и не согласен, что сферический юзкеис в вакууме, но лично меня больше волнует другой случай. Если систему взламывают (и нашли дыру), что привело к зависанию системы, то перезагружать до тех пор, пока хакеры не подберут правильное смещение -- это самый плохой подход. И существует тонна других примеров, когда не нужно ничего автоматически перезапускать. Если произошла ошибка -- с ней обычно нужно сначала разобраться. Достаточно редко бывают другие ситуации.
>> или заклинивший движок только начал перегреваться и еще не сгорел ...
> Autorecloser'у пофиг. Он попробует перезапустить линию в допущении что, возможно, это transient.
> Чаще всего так и оказывается. По поводу чего autorecloser'ы и применяют.
> Мало кто хочет разыскивать испарившийся дрист птички на изолятор или сгоревшую
> ветку, тратя на это время бригады.Не надо строить полных аналогий между электросетями и системным администрированием. Всё-таки совершенно разные вещи. Электросети не обрабатывают данные, которые могут корёжиться после каждой перезагрузки, их не взламывают и т.п.
>> тyпой перезапуск через вачдог может сделать еще хуже.
> Я обычно затачиваю железки под автопилот так, что они выходят на режим
> после подачи питания, не требуя внимания. Совсем. Аппаратный ресет - то
> же что и переподача питания. Железка должна штатно выйти на режим.
> Если это не так, я где-то облажался и это мой баг
> системной интеграции. Разрушение ФС? Можно держать rootfs readonly в большинстве случаев,
> или минимизировать записи (флеш к тому же запись не любит). А
> runtime данные хранить в tmpfs/zram/.... - требования к их non-volatile'ности, потерям
> и прочему весьма дико варьируются.А бывают ещё задачи кроме тех, которые выполняете вы. Где, например, намного эффективнее реализовывать высокую доступность через избыточность серверов, а баги рассматривать вручную и исправлять, вместо перезапусков.
>> Если уж серьезно относится к безотказности - то я бы сделал отдельный
>> девайс для ресета, который ждет sms/email с паролем.
> А кто будет проверять проверяющего? И вас не смущает, что сотовый модем
> - это еще несколько мегов черти-какого кода, сложный протокол, целая ОС
> в симкарте, и в общем то не очень надежная сеть? Не
> говоря о том что сотовый модем ощутимо удорожает и усложняет конструкцию.
> Надежность такой сбрасывалки будет врядли выше надежности вачдога. И будет много
> иных факторов. Ну там сотовый модем. Его ОС и вачдоги. И
> насколько он там выкручивается из разных ситуаций.. нуу... вот вы как
> раз на себе и протестируете ;].У нас был случай, когда головной узел HPC-шного кластера перезагрузился по watchdog-у тупо из-за того, что не успел ответить, так как был слишком сильно нагружен. Но забавно, что в результате перезагрузки были потеряны некоторые полезные данные, а без перезагрузки всё бы прошло само через несколько минут.
Watchdog нужен только там, где он действительно нужен.
>>> поэтому ваши аргументы для меня звучат как отмазка.
>> Естественно они есть, но причем здесь вачдог? Вачдог нужен когда железо/драйвер шалит,
> Вачдог нужен для восстановления работы сбойнувшей системы в ожидаемое состояние, за разумное
> время, без внешний воздействий. Причин по которым система может сбойнуть -
> много. И многие из них - transient.Не надо все задачи в мире равнять на ваши.
>> дабы обнулить состояние всех регистров и стартануть все с нуля.
> В общем случае вачдог обеспечивает восстановление после transient сбоев. Нечто типа autorecloser'а
> у электриков.Не надо электриков равнять с сисадминами.
>> Pi-образный девайс на два порядка сложнее МК,
> А связка Pi-образный + МК будет еще сложнее чем каждый по отдельности.
> А основы теории надежности говорят нам что так будет еще менее
> надежно.Так и не надо их совмещать без необходимости.
>> соответственно вероятность отказа на два (а может и более) порядка выше.
> А с практической точки зрения - железяки показывают вполне приличную надежность.А МК ещё более приличную. И стоят гораздо дешевле. Какой-нибудь STM32F0xx стоит порядка 50р (в текущими курсами валют) [1]. Пихать вместо него RPi без реальной необходимости -- это просто растрата.
[1] http://www.chipdip.ru/product/stm32f030f4p6/
>> Для особо критичных задач МК можно продублировать - на цене это особо не скажется.
> Дублируйте наздоровье. Вот только сколько МК не дублируй, а например картинку с
> usb-камеры на хард микроконтроллером не запишешь.Вообще-то камеру к МК приделать можно. А сохранять на SD-карту так вообще легкотня.
Вам принципиально, чтобы камера была именно USB, а устройство хранения -- HDD? Если да, то это странно, но могу погуглить на эту тему (никогда не интересовался такими решениями и сходу не знаю как тут дела обстоят).
> А юзер врядли будет рад
> узнать что девайс оказывается уже 2 дня груши околачивает и ничего
> не наблюдает.Кстати говоря, кроме камер бывают и другие датчики. И зачем тут винчестер? Wi-fi или ещё какой "коннективити" (как вы выражаетесь) тоже приделывается к МК. Я вот недавно закупил Wi-Fi модулей по 160р.
>> движок даже заглохнуть не успевал между перезагрузками МК :)
> Ну так я не собираюсь делать систему зажигания на апликушном проце. Там
> наверное приличные требования к реалтайму, а сильно много мозгов как у
> апликушника - куда их там?Можно пример задачи, где не хватает МК, чтобы понять о чём конкретно сейчас речь?
И ответьте, пожалуйста на мои вопросы тут:
http://www.opennet.me/openforum/vsluhforumID3/104497.html#170
> может влиять на работу запускаемых приложений.Если вы хотите систему, где вообще никто, никогда и ничего не меняет параллельно с вами - используйте MSDOS.
А в многозадачке потенциально всегда может что-то меняться. Глупые люди имеют свойство на это забивать. А потом - какой-нибудь ntp приходит и переводит часы. Ну а гомнокод от таких умников или висит неделю как тряпочка, или внепланово срабатывает. Досявое мышление заканчивается так.
> Например один демон, который я писал, сам для себя выставляет cgroup, seccomp и прочее.
Только это геморно и тех кто это делет - очень мало. А мне теперь не придется заниматься выписыванием такого кода в каждом первом сервисе.
> привет от Леннарта.[/offtop]
Все бы ничего, но
1) Леннарт уже давно этим не занимается.
2) Знаете, когда в алсе кто-то монопольно занял девайс - тоже не сильно понятнее что и кто.> Чем OpenRC не устраивет?
Это "sysv init на стероидах". Зачем мне это? Systemd - решает мои проблемы администрирования. Просто и комфортно в большинстве случаев. Он не запрещает вызывать внешние скрипты для реализации сложной логики. Но на мое мнение сложной логики в стартовой последовательности системы быть должно минимум. Иначе потом через 2 года мозг сломаешь "откуда же это берется?".
Поттеринг взялся разруливать проблемы администрирования. И у него это получилось. Лучше чем было до него. За это он и симпатичен такой толпени майнтайнеров и разработчиков. А OpenRC что пытается сделать? "Sysv init с заплатками"? Спасибо, но мне это не надо. И даже задачи "как прикрутить syslog-ng" у меня нет. У меня задачи иначе формулируются: "как залоггить сообщение" или "посмотреть сообщения от somecrapd за последние полчаса".
> И даже какой-то supervisor туда тоже впиливали. Хотя ниразу им не пользовалсяс.
Зато им пользуюсь я. И весит это меньше, чем shell гоняющий while true. И не висит в списке процессов левыми процессами шелла. И в отличие от - в курсе множества failure modes. Взвис на старте? Взвис при остановке? Взвис в run time? Вываливание с кодом ошибки? Затык ребута? Системд в курсе что так бывает. А while true надо превратить в большой блок кода, с конфигурацией, чтобы он стал сколь-нибудь эквивалентным. Нафиг надо.
> Какое удивление? О чём речь? Ниразу при передаче/получении сервера у меня не
> было таких проблем.Зато я видал как черти-как писаный гомнокод работает. В том числе и супервизор отпадения сервиса писаный на кроне и шелскрипте. Ненене, дэвид блейн, мне шапочные взгляды на это логичнее и симпатичнее.
> не помогут защитить сервер от тонны нечитаемых костылей.
Однако, с системд заниматься непотребством будет более некомфортно. Это уменьшит частоту проблем.
> Тем ни менее насколько сложно будет пользоваться systemd, если заменить udev наместо mdev?
Systemd, как я понимаю, технически udev для работы не требуется. Насколько это сложно обтяпать и какие там будут грабли - я не знаю. А зачем мне такая конфига нужна? У этого есть какое-то рациональное real-world обоснование, не высocaнное из пальца?
> openrc-шные скрипты минимальны по своему размеру.
А там как обычно, да? Ну там забили на логгинг кодов возврата, сохранение в лог вывода программы при ошибке, всякие там таймауты и прочие вещи, без которых не понятно "почему ничего не работает" и много глупых грабель на ровном месте.
> специфичной настройки контейнера -- это был очень неприятный момент.
Сел я тут в автобус. И узнал что он оказывается не может заехать на горную вершину. Облом, однако. Оказывается, автобусные маршруты прокладывают там где кто-то еще и ездить будет. И не 10 человек в год. И есть технические ограничения.
> Да, уже исправили, но было неприятно.
У всяких sysv init - случаются затыки даже с очень простыми и очевидными системными хотелками. Начиная от понимания "откуда это берется?" до реализации вачдога, таймаутов или логинга кодов возврата и вывода программы. Не говоря уж про всякие seccomp и смены шедулеров.
> привело к зависанию системы, то перезагружать до тех пор, пока хакеры
> не подберут правильное смещение -- это самый плохой подход.Ребут - достаточно заметное событие. И если это сервер и он нормально админится, админ должен бы заинтересоваться почему там много ребутов подряд. А еще - journald'шные логи проблематично подтереть задним числом. А текстовые - запросто. Стереть строку с "своей" записью много ума не надо. Это будет полностью незаметно для админа. Сказ про ремотный логгинг - круто, но - другие допущения. И еще: кто будет проверять проверяющего?
> И существует тонна других примеров, когда не нужно ничего автоматически перезапускать.
ЧСХ, в systemd автоматический перезапуск - штука опциональная. Зато когда становится надо - очень хорошо, что так можно. И еще лучше что все это настраивается.
> Если произошла ошибка -- с ней обычно нужно сначала разобраться.
Это "обычно" может весьма варьироваться. Может быть автопилотная инсталляция, где с ошибкой разбираться некому. Более того, таких инсталляций много. У поттера почему-то есть нормальный тулинг для всего этого. И он в отличие от - решает проблемы, а не лечит что такие юзкейсы требоваться не должны. За это он получает 5 очков форы перед конкурентами.
> Достаточно редко бывают другие ситуации.
На один твой пыльный сервер - две дюжины юнитов эмбедовки и околоэмбедовки. Где категорически некому жать ресет и изучать ошибки.
> Не надо строить полных аналогий между электросетями и системным администрированием.
Тем не менее, некоторые инженерные практики местами перекликаются. Никто не хочет гнать человеков за тридевять земель чтобы нажать ресет на какой-то дряни.
> Всё-таки совершенно разные вещи.
Но есть кое-какие схожие требования: постоянная работа. С минимальным обслуживанием, по возможности.
> Электросети не обрабатывают данные,
Это тебе так кажется. Подумай о том что в сети 50Гц все генераторы должны быть идеально синхронизированы. А стыковка больших систем и перераспределение нагрузки по хорошему довольно интеллектуальные операции требующие приличной аналитики и умной реакции.
То что так не всегда и не везде - скорее сделствие исторических причин. Пока не было лопат - пользовались палкой-копалкой. А когда поняли что лопаты порой маловато - сделали экскаваторы.
> которые могут корёжиться после каждой перезагрузки, их не взламывают и т.п.
У них периодически случаются факапы. Там провод оборвался, там хак...воры провод сперли. А вон трансформатор #$%нул. И очень кстати если grid в целом еще и не завалится от подобных вещей, еще более кстати если grid будет уметь перекоммутировать нагрузку и взаимодействовать с другими grid-ами.
В любом случае, у них тоже бывают transient и permanent сбои. И им тоже не хочется бегать и обслуживать что-то, если этого можно избежать.
> А бывают ещё задачи кроме тех, которые выполняете вы.
Ну разумеется.
> Где, например, намного эффективнее реализовывать высокую доступность через избыточность > серверов, а баги рассматривать вручную и исправлять, вместо перезапусков.
Так я что, против? Просто это дороже. И у них обычно системы тоже ориентированы на бесперебойную работу, прежде всего. А анализ ошибок - может быть. Но в большой инфраструктуре всегда будет эн проблем. Если у вас миллион серверов - где винч сдох, где-то память глючит, где проц барахлит, где питальник помер. При этом просто меняется юнит администрирования: сервак могут просто заменить целиком. А детальные изучения что и почему - таки обычно не в живой структуре, а в фоне и сбоку. Кстати VM по этому поводу всем нравятся, с ними так проще всего. И развязка логики от физики. И системы по этому поводу раскатывают из шаблонов за минуты в общем случае.
> полезные данные, а без перезагрузки всё бы прошло само через несколько минут.
Иногда вачдог может быть и не тем что хотелось. Но тем не менее, затык активности на несколько минут - это в общем случае ошибка программирования. Система не должна вставать колом на несколько минут, имхо. Ну то-есть есть энное количество задач где такая латенси приемлима, но по дефолту я такое считаю ошибкой программирования или администрирования.
> Watchdog нужен только там, где он действительно нужен.
Со своей стороны я в общем случае считаю время реакции системы измеряемой МИНУТАМИ жирным багом программирования, который надо чинить.
> Не надо все задачи в мире равнять на ваши.
Вот к себе это и примените. В случае системды - там опций на разные задачи почему-то есть. И перенастраивается изрядно.
> Так и не надо их совмещать без необходимости.
Ну так у микроконтроллера - ограничение по ресурсам. Он не может считать как апликушный проц.
> А МК ещё более приличную. И стоят гораздо дешевле. Какой-нибудь STM32F0xx стоит
> порядка 50р (в текущими курсами валют)Да я в курсе :). Урвал мелкооптовую партию таковых, по $0.8 и иному курсу. Мне их теперь надолго хватит. Но вот вебфэйс я так делать не буду. И картинку с usb-камеры на sata hdd я так записывать не стану. И по PPTP через эзернет я на МК конектиться не буду. И с сотовым модемом разве что с промышленным модулем работать. Совсем не ширпотребная штука и не очень дешевая. И GPRS-only в основном. А хотя-бы 3G - уже совсем отдельная сказка. С отдельной ценой. Usb-свисток из ближайшего ларька дешевле и шустрее. И еще вопрос кто менее надежен.
> без реальной необходимости -- это просто растрата.
Смотря что понимать под реальной необходимостью. Тем более что Pi - готовое устройство. А для STM надо печатную плату. Для себя я условно-бесплатно наЛУТаю. Но вот пуск в производство платы - время и $. Инженерные решения - о выборе разумного набора компромиссов.
> Вообще-то камеру к МК приделать можно.
Но вот ресурсы там - не те. И фиг вы 720P@30FPS в реальном времени обсчитаете. И винч на терабайт не прицепите без отдельных извратов. И камера потребуется экзотичная.
> А сохранять на SD-карту так вообще легкотня.
При том обычно на дрянь типа FAT. С никаким разрешением. И кучей дурных ограничений. И картинка вида "китайский тетрис снимает лучше".
> Вам принципиально, чтобы камера была именно USB, а устройство хранения -- HDD?
Мне принципиально, чтобы параметры были конкурентоспособны, по разумной цене, с разумными затратами времени и сил. А "тетрис" с массой ограничений, требующий времени разработки в 5 раз больше - вы и разрабатывайте.
Сильный кодек типа H.264 (или VPx) на мк крутить не выйдет. И картинку в браузер не передашь. И алерт на почту "тут какое-то движение" из мк передавать неудобно. Особенно когда хочется чтобы адрес почты юзер мог бы и конфигурировать без мытарств.
> (никогда не интересовался такими решениями и сходу не знаю как тут дела обстоят).
Как я уже сказал, любое решение - набор компромиссов. Да, можно прицепить камеру к МК. Но только вот не забудьте поинтересоваться какой там объем данных при человеческих разрешениях и FPSах. А заодно подумайте как это выплюнуть в сеть и как сделать чтобы юзер мог перенастроить емыл без мучений.
> Кстати говоря, кроме камер бывают и другие датчики.
Ну вот поэтому до кучи может хотеться поклацать каким-нибудь реле. И не всегда там злые требования к реалтаймности и прочая. Разумеется, обмотки BLDC коммутировать апликушником будет лишь дypaк или извращенец.
> И зачем тут винчестер?
А потому что на него влезет уйма видео с приличным качеством за солидное время. И он не загнется от активной записи, в отличие от SD карты.
> Я вот недавно закупил Wi-Fi модулей по 160р.
При том там хзкакая проприетарная прошивка, неизвестной степени безопасности, в 5 раз сложнее фирмвары вашего МК. С кучей дурных допущений и ограничений. Что ни говори, а у линуха сетевой стек развитее. И - опенсорсный. Как инженер - я не подпишусь за сетевую безопасность черти-какого модуля с мегабайтом проприетарного кода, реализуюшего протокол.
Ну и сделали вы девайс. И как юзеру его настраивать в человеческом формате, интересно? Ну там хоть параметры беспровдной сети вбить.
> Можно пример задачи, где не хватает МК, чтобы понять о чём конкретно сейчас речь?
Любая задача где:
- Развитое конективити в нормальные сети, без глупых ограничений.
- Обработка существенного объема данных или интенсивная математика. Сильные кодеки, шифрование, etc.
- Сколь-нибудь развитый юзеринтерфейс.
- Нужда или желание работать с "большой" PC-образной периферией.В результате - с практической точки зрения, предложенные вами решения - геморны в реализации и обладают хреновыми параметрами и неудобны для пользователя. И при небольшом тираже, удешевление юнита ценой увеличения времени разработки это FAIL. А продать миллион таких уpoдцев, где мк с камерой - ок, попробуйте.
> И ответьте, пожалуйста на мои вопросы тут:
Вроде ответил.
>> может влиять на работу запускаемых приложений.
> Если вы хотите систему, где вообще никто, никогда и ничего не меняет
> параллельно с вами - используйте MSDOS.Причём тут параллельный запуск? Я говорил вообще-то про последовательные операции (сначала изменить cgroups, а потом запустить), а не параллельные.
Но даже если так, что MSDOS — это как минимум не свободное решение, которое абсолютно не решает моих задач чисто технически.
> А в многозадачке потенциально всегда может что-то меняться. Глупые люди имеют свойство
> на это забивать. А потом - какой-нибудь ntp приходит и переводит
> часы. Ну а гомнокод от таких умников или висит неделю как
> тряпочка, или внепланово срабатывает. Досявое мышление заканчивается так.So what? Вы это вообще к чему?
>> Например один демон, который я писал, сам для себя выставляет cgroup, seccomp и прочее.
> Только это геморно и тех кто это делет - очень мало. А
> мне теперь не придется заниматься выписыванием такого кода в каждом первом
> сервисе.У очень многих приложений могут быть свои особенности вызывающие те или иные проблемы. А когда основная системная запускалка — это мегамонстр, который любит отвечать тупо "Connection refused" вместо подробного описания проблемы, то это сильно усложняет лично мою жизнь. Да, я действительно использую systemd на некоторых системах. Думал, что может привыкну и станет лучше, а оказалось, что привык и понял, что всё ещё хуже, чем я думал.
>> привет от Леннарта.[/offtop]
> Все бы ничего, но
> 1) Леннарт уже давно этим не занимается.Ну да, он любит бросать проекты. Когда systemd тоже бросит и тот тоже начнёт себя так вести, то что?
Когда в pulseaudio был Леннарт, это был глюкавый падучий пш-пш. А когда Леннарта не стало — стало лучше, но вот DISPLAY недавно порадовал. До этого проблемы с bluetooth очень порадовали и многое другое.
> 2) Знаете, когда в алсе кто-то монопольно занял девайс - тоже не
> сильно понятнее что и кто.Не понял этот тезис. Что значит «понятнее что и кто»? Речь про «lsof -n /dev/snd/*»? Я вообще любитель OSS, но на Linux пользуюсь ALSA из-за размера комьюнити (да и на нём тоже можно жить). PulseAudio ничего нового (из полезного) толком не изобрёл. Вообще не хотел бы ещё и на эту тему тут спорить, вы и так пишите очень много текста, что заставляет тратить очень много времени на тупо набор текста-ответа.
>> Чем OpenRC не устраивет?
> Это "sysv init на стероидах". Зачем мне это?Затем, что он хорошо решает задачи, сохраняя прозрачность и хорошую полноценную модульность. И появился раньше, и управляется/развивается полностью свободным сообществом а не RH.
> Systemd - решает мои
> проблемы администрирования. Просто и комфортно в большинстве случаев. Он не запрещает
> вызывать внешние скрипты для реализации сложной логики. Но на мое мнение
> сложной логики в стартовой последовательности системы быть должно минимум. Иначе потом
> через 2 года мозг сломаешь "откуда же это берется?".OpenRC тоже решает проблемы комфортно администрирования без искусственной необходимости ручного описания сложной логики.
> Поттеринг взялся разруливать проблемы администрирования.
Которых и так не было, IMHO.
> И у него это получилось. Лучше
> чем было до него. За это он и симпатичен такой толпени
> майнтайнеров и разработчиков. А OpenRC что пытается сделать? "Sysv init с
> заплатками"? Спасибо, но мне это не надо. И даже задачи "как
> прикрутить syslog-ng" у меня нет.Рад за вас.
> У меня задачи иначе формулируются: "как
> залоггить сообщение" или "посмотреть сообщения от somecrapd за последние полчаса".Это просто другие задачи.
>> И даже какой-то supervisor туда тоже впиливали. Хотя ниразу им не пользовалсяс.
> Зато им пользуюсь я. И весит это меньше, чем shell гоняющий while
> true. И не висит в списке процессов левыми процессами шелла. И
> в отличие от - в курсе множества failure modes. Взвис на
> старте? Взвис при остановке? Взвис в run time? Вываливание с кодом
> ошибки? Затык ребута?Это всё не имеет отношения к OpenRC.
> Системд в курсе что так бывает.
И при этом сам при некоторых условиях успешно зависает.
>> Какое удивление? О чём речь? Ниразу при передаче/получении сервера у меня не
>> было таких проблем.
> Зато я видал как черти-как писаный гомнокод работает. В том числе и
> супервизор отпадения сервиса писаный на кроне и шелскрипте. Ненене, дэвид блейн,
> мне шапочные взгляды на это логичнее и симпатичнее.
>> не помогут защитить сервер от тонны нечитаемых костылей.
> Однако, с системд заниматься непотребством будет более некомфортно. Это уменьшит частоту
> проблем.Он просто их абстрагирует. И если будут проблемы, в которых уже учавствует systemd, то диагностировать их становится уже сложнее, ибо это монстр который творит много всего.
>> Тем ни менее насколько сложно будет пользоваться systemd, если заменить udev наместо mdev?
> Systemd, как я понимаю, технически udev для работы не требуется. Насколько это
> сложно обтяпать и какие там будут грабли - я не знаю.
> А зачем мне такая конфига нужна? У этого есть какое-то рациональное
> real-world обоснование, не высocaнное из пальца?Когда-то, когда я жил на FreeBSD, у меня никогда не было проблем, что после обновления сетевые интерфейсы стали именоваться как-то через жопу, как и многих других проблем. Я вообще с монстрами менее эффективно работаю, чем с минималистичными решениями.
>> openrc-шные скрипты минимальны по своему размеру.
> А там как обычно, да? Ну там забили на логгинг кодов возврата,
> сохранение в лог вывода программы при ошибке, всякие там таймауты и
> прочие вещи, без которых не понятно "почему ничего не работает" и
> много глупых грабель на ровном месте.[/me призывает:] Bircoph, ты как gentoo-dev ответь, пожалуйста. Вдруг я где-то отвечу неточно, случайно.
>> специфичной настройки контейнера -- это был очень неприятный момент.
> Сел я тут в автобус. И узнал что он оказывается не может
> заехать на горную вершину. Облом, однако. Оказывается, автобусные маршруты прокладывают
> там где кто-то еще и ездить будет. И не 10 человек
> в год. И есть технические ограничения.Ну, мы занимаемся большим количеством кастомных решений (специфика нашего отдела такая). И я почему-то такой невезучий человек, что у меня постоянно с этим systemd много неожиданных проблем. Дошло до того, что мы были вынуждены всё-таки использовать для большинства систем openrc на Debian несмотря на малый комьюнити вокруг него (в Debian).
>> Да, уже исправили, но было неприятно.
> У всяких sysv init - случаются затыки даже с очень простыми и
> очевидными системными хотелками. Начиная от понимания "откуда это берется?" до реализации
> вачдога,Какие проблемы с watchdog?
> таймаутов или логинга кодов возврата и вывода программы.
Вы пробовали OpenRC? Вы утверждаете, что то как сделано в OpenRC вас не устраивает, я правильно понял?
> Не говоря уж про всякие seccomp
С одной стороны:
- Вообще говоря, seccomp лучше всего настраивать после инициализации (после setuid()-ов, exec()-ов и всего лишнего, что не требуется во время работы и завершения). Поэтому seccomp должен использоваться внутри приложения.
- Внешний seccomp очень опасен для обеспечения работоспособности приложения. Обновилась версия ПО и начало оно использовать новые функции — и что дальше? Сменился libc и начал использовать другие syscall-ы для тех же самых функций — и что дальше? И т.п. На мой взгляд seccomp — это advanced security feature для advanced users, и включать его извне — это бред. Только автор программы настолько хорошо знает программу, что понимает как нужно настраивать seccomp.С другой стороны:
Я согласен, что дополнительный слой защиты (даже если он хуже, чем мог бы быть) — это хорошо.
Теперь по сути:
- Это упущение, что нет отдельного seccomp wrapper в стандартных репозиториях того же Debian (хотя может быть он и есть, а я о нём просто не знаю). Если бы он был, то подключить его в OpenRC — элементарное дело. Это никто не делает лишь потому, что так не надо делать, IMHO, так как работы сис. админам сильно прибавится.
- Если говорить про очень грубу настройку seccomp (чтобы точно не мешать работе приложений), то она и так делается с помощью lxc, где у меня и развернуты все чувствительные сервисы.В результате я не вижу какую проблему решил systemd своим появлением.
> и смены шедулеров.
Что имеется в виду под «сменой шедулеров»?
>> привело к зависанию системы, то перезагружать до тех пор, пока хакеры
>> не подберут правильное смещение -- это самый плохой подход.
> Ребут - достаточно заметное событие. И если это сервер и он нормально
> админится, админ должен бы заинтересоваться почему там много ребутов подряд.Это может произойти в 3 часа ночи.
> А еще - journald'шные логи проблематично подтереть задним числом. А текстовые -
> запросто.journald-шные логи подписываются что ли? Если бы даже было бы и так, то что сложного то же самое делать с человекочитабельными логами? Хотя лично у меня так вообще логи льются на отдельный сильнозащищённый сервер с syslog-ng, откуда уже никто ничего потереть не сможет.
> Стереть строку с "своей" записью много ума не надо. Это
> будет полностью незаметно для админа. Сказ про ремотный логгинг - круто,
> но - другие допущения. И еще: кто будет проверять проверяющего?Что такое «ремонтный логгинг»?
>> И существует тонна других примеров, когда не нужно ничего автоматически перезапускать.
> ЧСХ, в systemd автоматический перезапуск - штука опциональная. Зато когда становится надо
> - очень хорошо, что так можно. И еще лучше что все
> это настраивается.Вообще-то для OpenRC тоже есть решение на базе cgroups для опционального перезапуска приложений. Не знаю затолкнуто ли это в upstream — не интересовался уже давно…
>> Если произошла ошибка -- с ней обычно нужно сначала разобраться.
> Это "обычно" может весьма варьироваться. Может быть автопилотная инсталляция, где с ошибкой
> разбираться некому.Исталляция чего? ОС? Зачём её перезапускать? И как её перезапустить с помощью systemd?
>> Достаточно редко бывают другие ситуации.
> На один твой пыльный сервер - две дюжины юнитов эмбедовки и околоэмбедовки.
> Где категорически некому жать ресет и изучать ошибки.Можно конкретный use case (embedd-овый)?
>> Не надо строить полных аналогий между электросетями и системным администрированием.
> Тем не менее, некоторые инженерные практики местами перекликаются. Никто не хочет гнать
> человеков за тридевять земель чтобы нажать ресет на какой-то дряни.
>> Всё-таки совершенно разные вещи.
> Но есть кое-какие схожие требования: постоянная работа. С минимальным обслуживанием, по
> возможности.И туева хуча несхожих требований.
>> Электросети не обрабатывают данные,
> Это тебе так кажется. Подумай о том что в сети 50Гц все
> генераторы должны быть идеально синхронизированы. А стыковка больших систем и перераспределение
> нагрузки по хорошему довольно интеллектуальные операции требующие приличной аналитики
> и умной реакции.Речь про какой-то сельсин? Или про что конкретно?
А если говорить конкретно про нашу гос. контору, то она платит более 50млн. в год на электропитание, и у нас в электросети нет ничего того, о чём вы говорите. Совершенно никаких сложностей, все технологии дубовые.
> То что так не всегда и не везде - скорее сделствие исторических
> причин. Пока не было лопат - пользовались палкой-копалкой. А когда поняли
> что лопаты порой маловато - сделали экскаваторы.Вот только чтобы забивать гвозди я дома держу обычный молоток («изобретённый» хрен знает когда), хотя бывают и более хитрые средства.
>> которые могут корёжиться после каждой перезагрузки, их не взламывают и т.п.
> У них периодически случаются факапы. Там провод оборвался, там хак...воры провод сперли.
> А вон трансформатор #$%нул. И очень кстати если grid в целом
> еще и не завалится от подобных вещей, еще более кстати если
> grid будет уметь перекоммутировать нагрузку и взаимодействовать с другими grid-ами.Мне казалось, что это уже задача контроллеров (то есть программистов, а не электриков).
>> полезные данные, а без перезагрузки всё бы прошло само через несколько минут.
> Иногда вачдог может быть и не тем что хотелось. Но тем не
> менее, затык активности на несколько минут - это в общем случае
> ошибка программирования. Система не должна вставать колом на несколько минут, имхо.
> Ну то-есть есть энное количество задач где такая латенси приемлима, но
> по дефолту я такое считаю ошибкой программирования или администрирования.Каждая задача требует своих инструментов. Watchdog легко прикручивается куда надо. Однако намного проще делать надёжную систему, когда она легко собирается из минимальных необходимых блоков без применения монстров, пытающихся решать сразу все проблему (и те что есть, и те, которых нет). Да, в systemd всё настраиваемо, но всё равно образуется много лишнего пространства для проблем; а многое для настройки требует пересборки.
>> Watchdog нужен только там, где он действительно нужен.
> Со своей стороны я в общем случае считаю время реакции системы измеряемой
> МИНУТАМИ жирным багом программирования, который надо чинить.Бывают системы, где downtime пару часов — это приемлемо. Бывают системы, где доступность обеспечивается другими способами (а не перезагрузкой).
>> Не надо все задачи в мире равнять на ваши.
> Вот к себе это и примените. В случае системды - там опций
> на разные задачи почему-то есть. И перенастраивается изрядно.Это монструозная абстракция, которая лично с моей точки зрения (с точки зрения моих use case-ов) поборола уже n-ую ветряную мельницу. Я на своих системах уже отловил немало багов. В частности из-за работы с seccomp и многим другим. И нафига это всё было нужно, если openrc решает мои задачи не хуже (с точки зрения затрат моих человекочасов), но таких проблем не создаёт?
>> Так и не надо их совмещать без необходимости.
> Ну так у микроконтроллера - ограничение по ресурсам. Он не может считать
> как апликушный проц.Это понятно, но всё равно можно конкретный use case? Я просто не сталкивался с задачами, куда не смог найти микроконтроллер с нужной производительностью. Вот найти АЦП за хорошую цену с нужной частотой выборки — это другой вопрос, но это уже другая тема для обсуждения.
У меня была всего пара случаев, когда требовались большие ресурсы для выполнения конкретной задачи, в обоих случаях я просто пересылал данные с МК на сервер, где эти данные обрабатывались. В одном случае по ethernet, в другом случае — по bluetooth.
>> А МК ещё более приличную. И стоят гораздо дешевле. Какой-нибудь STM32F0xx стоит
>> порядка 50р (в текущими курсами валют)
> Да я в курсе :). Урвал мелкооптовую партию таковых, по $0.8 и
> иному курсу. Мне их теперь надолго хватит. Но вот вебфэйс я
> так делать не буду.Согласен. Хотя видел такие извраты :). Однако для «вебфэйсов» есть полноценные серверы, зачем тут всякие embedded-ы и т.п.?
> И картинку с usb-камеры на sata hdd
> я так записывать не стану.USB и SATA — это принципиально?
> И по PPTP через эзернет я на МК конектиться не буду.
Не удивлюсь, что бывают готовые библиотечки для чего-нибудь мега-популярного вроде Arduino или Nucleo (на mbed.org, например). Однако опять же PPTP — это принципиально? Не хватит Wi-Fi с WPA2 до сервера, который уже умеет PPTP?
> И с сотовым модемом разве что
> с промышленным модулем работать. Совсем не ширпотребная штука и не очень
> дешевая. И GPRS-only в основном. А хотя-бы 3G - уже совсем
> отдельная сказка. С отдельной ценой.
> Usb-свисток из ближайшего ларька дешевле и
> шустрее. И еще вопрос кто менее надежен.Хотите сказать, что GSM-модуль стоит дорого?
>> без реальной необходимости -- это просто растрата.
> Смотря что понимать под реальной необходимостью. Тем более что Pi - готовое
> устройство. А для STM надо печатную плату.Есть Nucleo для ленивых, но он дороговат (подходит скорее как платформа для разработки, чем для production-а, IMHO). А распечатать плату, если она уже разработана — IMHO, не проблема. Если не хочется самому печатать, то есть всякие там «Резониты».
> Для себя я условно-бесплатно
> наЛУТаю. Но вот пуск в производство платы - время и $.
> Инженерные решения - о выборе разумного набора компромиссов.Понятно. Как всегда всё зависит от конкретной задачи. Можете всё-таки рассказать конкретные задачи, которые вы решаете, чтобы я наконец начал вас понимать? :)
>> Вообще-то камеру к МК приделать можно.
> Но вот ресурсы там - не те. И фиг вы 720P@30FPS в
> реальном времени обсчитаете. И винч на терабайт не прицепите без отдельных
> извратов. И камера потребуется экзотичная.Такую задачу не решал, своего мнения для данного use case-а не имею, пока что. Однако зачем вообще решают такую задачу? Разрабатываете системы видеонаблюдения?
Когда для дома just4fun решал такую задачу, то да, применил RPi. Но не понимаю зачем мне такое могло бы пригодиться в production-е. Системы видеонаблюдения существуют и без наших разработок, а автоматика обычно не требует видеосъёмки — процесс можно контролировать автоматически и через другие датчики.
>> А сохранять на SD-карту так вообще легкотня.
> При том обычно на дрянь типа FAT.Ну, мы — извращенцы и предпочитаем работать без файловой системы, если чисто логически речь про один поток данных.
>> Вам принципиально, чтобы камера была именно USB, а устройство хранения -- HDD?
> Мне принципиально, чтобы параметры были конкурентоспособны, по разумной цене, с разумными
> затратами времени и сил. А "тетрис" с массой ограничений, требующий времени
> разработки в 5 раз больше - вы и разрабатывайте.
> Сильный кодек типа H.264 (или VPx) на мк крутить не выйдет.
> И картинку в браузер не передашь.Зачем это делать на чём-то кроме полноценного сервера/десктопа? Это не сарказм, вопрос искренний.
> И алерт на почту "тут какое-то
> движение" из мк передавать неудобно. Особенно когда хочется чтобы адрес почты
> юзер мог бы и конфигурировать без мытарств.Так пусть МК как угодно сообщает в сеть о проблеме, а далее нужный сервер уже поймёт, что нужно отправлять письмо. Простите ламера (всё это сильно выходит за рамки моих основных обязательств).
>> (никогда не интересовался такими решениями и сходу не знаю как тут дела обстоят).
> Как я уже сказал, любое решение - набор компромиссов. Да, можно прицепить
> камеру к МК. Но только вот не забудьте поинтересоваться какой там
> объем данных при человеческих разрешениях и FPSах.Я просто вообще не понимаю, зачем нужен большой FPS на таких системах. Если хочется посмотреть общее состояние дел, то достаточно и одной фотографии раз в минуту.
> А заодно подумайте как
> это выплюнуть в сеть и как сделать чтобы юзер мог перенастроить
> емыл без мучений.Выплюнуть в сеть — как раз не проблема. AFAIK, можно даже, например, сделать полноценное решение на базе ESP-12E (используя внутренний МК).
>> Кстати говоря, кроме камер бывают и другие датчики.
> Ну вот поэтому до кучи может хотеться поклацать каким-нибудь реле. И не
> всегда там злые требования к реалтаймности и прочая. Разумеется, обмотки BLDC
> коммутировать апликушником будет лишь дypaк или извращенец.Не понял связи. Я говорю о применимости МК для тех use case-ов, где многие предпочли бы использовать RPi-like, за счёт применения не тех датчиков, о которых они думали изначально. А вы говорите о том, чтобы использовать GPIO RPi-like для работы с реле, я правильно понял?
>> И зачем тут винчестер?
> А потому что на него влезет уйма видео с приличным качеством за
> солидное время. И он не загнется от активной записи, в отличие
> от SD карты.А почему нельзя передать по сети? Это какая-то автономная видеокамера, которая находится где-то в лесу? Мне кажется что для этого уже есть много готовых решений (не обязательно всё переизобретать). Или они дорогие? Или речь про импортозамещение?
>> Я вот недавно закупил Wi-Fi модулей по 160р.
> При том там хзкакая проприетарная прошивка, неизвестной степени безопасности, в 5 раз
> сложнее фирмвары вашего МК.Буду тестировать, но насколько мне известно — как раз-таки нет, там свой МК, который можно свободно программировать.
А вообще, в ваших сетевых тоже firmware проприетарный :). А многие сетевые так требуют даже, чтобы ядро ОС подгрузило проприетарный firmware. Но я не собираюсь использовать это как аргумент, просто напоминаю.
> Ну и сделали вы девайс. И как юзеру его настраивать в человеческом
> формате, интересно? Ну там хоть параметры беспровдной сети вбить.Пока не сделал, сейчас занят отчётами :(. А юзеру и не нужно будет его настраивать, ибо устройство под конкретную задачу. Один раз настроим и будет работать много лет без вмешательств. Исходный код, платы и прочее опубликуем, конечно же.
>> Можно пример задачи, где не хватает МК, чтобы понять о чём конкретно сейчас речь?
> Любая задача где:
> - Развитое конективити в нормальные сети, без глупых ограничений.Ограничение в 5 TCP-соединений — это глупое ограничение. Вам действительно на устройствах такого масштаба требуется 100500 соединений?
> - Обработка существенного объема данных или интенсивная математика. Сильные кодеки, шифрование,
Отправляйте на сервер и обрабатывайте там.
> etc.
> - Сколь-нибудь развитый юзеринтерфейс.Юзер — это тупой юзер? Тогда прикручиваешь экран и кнопки. Если юзер — это админ/программист, то достаточно просто написать документацию и сделать код, который легко понять как конфигурировать. Если же требуется интерактивная работа по ssh, то тогда сам интерфейс можно делать на каком-нибудь сервере, который по простому протоколу командует МК что нужно делать. Если хочется настраивать устройство, присоединив к десктопу, то вполне можно сделать «няшную» GUI-ёвину, которая общается с МК нужным образом.
> - Нужда или желание работать с "большой" PC-образной периферией.
Возможно это желание берётся чисто из инерции мышления, а не из реальной необходимости.
> В результате - с практической точки зрения, предложенные вами решения - геморны
> в реализации и обладают хреновыми параметрами и неудобны для пользователя. И
> при небольшом тираже, удешевление юнита ценой увеличения времени разработки это FAIL.
> А продать миллион таких уpoдцев, где мк с камерой - ок,
> попробуйте.Я просто так и не понял конкретной задачи.
Просто если это система масштаба RPi, то обычно она имеет «коннективити» и управляется удалённо без проблем, что уже делает всякие автоперезапускали далеко не всегда желаемыми. Если же это система более мелкого масштаба, то обычно хватает МК.
>> И ответьте, пожалуйста на мои вопросы тут:
> Вроде ответил.Нет, но и не надо уже. И так текста много :)
Мы на самом деле далеко ушли от сути. Вы, если я правильно понял, утверждаете, что ваши подходы к работе являются более правильными, и они выполняются более удобно с systemd. Я же с этим спорю, и считаю, systemd обычно слишком монструозен и скорее вреден, чем полезен… Хотя, возможно, я уже просто потерял нить диалога.Да, бывают use case-ы, где он хорош. Я вообще рад его появлению (всегда рад за СПО, когда там появляется что-то новое). Однако делать его по умолчанию, IMO, было ошибкой. Однако не мне это решать, а людям которые это заслужили — developer-ами соответствующих дистрибутивов. Поэтому я просто помог немного развитию openrc в Debian и пользую его. А когда меня пытаются убедить, что systemd — это хорошо, то я просто вспоминаю через что мне пришлось проходить в экстренном темпе и пытаюсь пояснить собеседнику, что systemd был хорош, пока он не был навязан простому пользователю, вроде меня.
>> Ну и сделали вы девайс. И как юзеру его настраивать в человеческом
>> формате, интересно? Ну там хоть параметры беспровдной сети вбить.
> Пока не сделал, сейчас занят отчётами :(.Чёрт, я прочёл «ну и сделали вы девайс» как вопрос про девайс с тем wifi-модулем за 160р. Поэтому ответил криво, извиняюсь :)
>> что systemd не вмешается в их работу.
> Systemd - не искусственный интеллект. Ничего особенного со скриптами он не делает.Как уже отметили, речь об состоянии системы, а не о интерпретации скрипта. Systemd/udev может изменить право доступа или имя устройства или создать динамически генерируемый конфиг - все это делает систему менее предсказуемой, сложнее точно сказать какие будут произведены действия в той или иной ситуации.
> А еще, если вы про экономию ресурсов - интерпретер шелла, висящий на
> каждый while true - ресурсов кушает. Поболее чем systemd на отслеживание
> процесса.Возможно, но не думаю что разница существенна при использовании sh (ash/dash)
> Посмотрите man systemd.exec, systemd.unit и systemd.service
Я принял ваши доводы. В большинстве случаев вся эта функциональность бесполезна, но для определенных ситуаций/сервисов может быть необходима. ИМХО хорошим решением было бы вынесением создание отдельной утилиты отвечающий за запуск сервиса (с обработкой ошибок, таймаутами, etc), не зависящей от системы инициализации. Тогда бы ее можно было бы при необходимости использовать с любой системой инициализации - и все довольны: не хочешь не используй и единое решение для всех дистрибутивов/систем инициализации. А проекты типа busybox могли бы включить облегченную реализацию.
>> Ну и толку - сдохла видюха на сервере, получим бесконечный ребут,
> Это какой-то совсем сферический юзкейс в вакууме. Для начала, в обычные сервера
> (и эмбедовку) нынче обычно не ставят дискретные видеокарты - 2015 год
> на дворе.То есть вы считаете что lockup видео драйвера происходит исключительно на дискретных видиокартах? Я видео карту как пример взял, так как сам тут поймал регрессию на радеонах ведущую к lockup в kernel-4.1. При том как на дискретной, так и на чипсете.
>> без возможности удаленно зайти на машину.
> Сервер крутится без графики и поэтому клин 1 из GPU всем пофигу.А как же - "У меня логика простая: система или делает то что должна, или уходит в ребут и восстанавливается в известное, работоспсобное и безглючное состояние." ?
>> Если уж серьезно относится к безотказности - то я бы сделал отдельный
>> девайс для ресета, который ждет sms/email с паролем.
> А кто будет проверять проверяющего? И вас не смущает, что сотовый модем
> - это еще несколько мегов черти-какого кода, сложный протокол, целая ОС
> в симкарте, и в общем то не очень надежная сеть?Любое дублирование существенно повышает шансы на безотказность. Можно взять три ненадежных элемента - ПК, сотовый модем с gpio, RBPi (ждущий email с паролем для ресета). И получить достаточно безотказный удаленный ресет.
> Не говоря о том что сотовый модем ощутимо удорожает и усложняет конструкцию.
Цена, это отдельный разговор - просто так (а бы было) такое никто сооружать не станет, а если будет реальная необходимость - то и продублируют, вплоть до управления со спутника.
> Надежность такой сбрасывалки будет врядли выше надежности вачдога. И будет много
> иных факторов. Ну там сотовый модем. Его ОС и вачдоги. И
> насколько он там выкручивается из разных ситуаций.. нуу... вот вы как
> раз на себе и протестируете ;].Всякие космонавты для таких случаев берут несколько девайсов на разных производителей и на разной элементной базе.
>>> поэтому ваши аргументы для меня звучат как отмазка.
>> Естественно они есть, но причем здесь вачдог? Вачдог нужен когда железо/драйвер шалит,
> Вачдог нужен для восстановления работы сбойнувшей системы в ожидаемое состояние, за разумное
> время, без внешний воздействий. Причин по которым система может сбойнуть -
> много. И многие из них - transient.ИМХО пока ядро живо, должны использоваться менее агрессивные средства (типа killall), а вачдог должен сработать только при зависании ядра либо при глухом (killall и рестарт не помогают) зависании служб/драйверов необходимых для удаленного управления.
>> Pi-образный девайс на два порядка сложнее МК,
> А связка Pi-образный + МК будет еще сложнее чем каждый по отдельности.
> А основы теории надежности говорят нам что так будет еще менее
> надежно.Нет, в поставленной вами задачи - мы выносим критическую задачу на МК (таймер и gpio), а не критическую (веб морда) на Pi-образный девайс.
>> соответственно вероятность отказа на два (а может и более) порядка выше.
> А с практической точки зрения - железяки показывают вполне приличную надежность.Возможно, но когда я пытался управлять насосом с выделенного ПК (не было тогда Pi-образный девайсов), я быстро понял свою ошибку ;)
> Вот только сколько МК не дублируй, а например картинку с
> usb-камеры на хард микроконтроллером не запишешь. А юзер врядли будет рад
> узнать что девайс оказывается уже 2 дня груши околачивает и ничего
> не наблюдает.Это совершенно другая задача, и как правило менее критичная, чем управление всякой автоматикой. Да и она в основном решается дублированием.
> Случаи разные бывают. И вы с вашими попытками серебряные
> пули втюхивать - смотритесь от "странно" до "глупо", имхо.Я просто предложил наиболее оптимальное решение для озвученной вами задачи. Где я говорил про универсальность и серебряные пули? У вообще жизненная позиция - выбирай для каждой задачи свое наиболее подходящее решение, а не одно универсальное. Все универсальное (компромиссное) будет по определению хуже специализированного (без компромиссное), за исключением когда универсальность - это и есть специализация.
> Ну так я не собираюсь делать систему зажигания на апликушном проце. Там
> наверное приличные требования к реалтайму, а сильно много мозгов как у
> апликушника - куда их там?Естественно.
>> Да но гарантировать bug free всего программного комплекса на RBPi/ПК невозможно, в
>> отличии от МК.
> Я вижу некое отличие между pi-like и писюком. В одноплатнике может быть
> 1 проц, без проприетарного кода (кроме может быть минимального boot rom,
> тривиального в анализе и логике работы). Это достаточно предсказуемая связка, где
> я контролирую все. Куда предскауемее писюшника с его BIOS, SMM и
> прочим крапом.Как не крути, а что на PC что на pi-like - миллионы строк кода, ненадежная загрузка (карта памяти или винт). Да железа на два порядка сложнее МК. Можно конечно сказать что на pi-like надежнее по железу (проще система питания, проще система охлаждения, меньше разъемов), но ИМХО pi-like будет надежнее в 2-3 раза, а МК - на порядок или два.
> Можно конечно сказать что на pi-like надежнее
> по железу (проще система питания, проще система охлаждения, меньше разъемов), но
> ИМХО pi-like будет надежнее в 2-3 разаКстати спорно. Мне попалась Pi, которая перезагружалась на высоких нагрузках (блок питания был с избыточной мощностью и проблема не в нём). Штука мощная, монструозная и дешёвая, поэтому там экономят на всём подряд, IMHO.
> Кстати спорно. Мне попалась Pi, которая перезагружалась на высоких нагрузках (блок питания
> был с избыточной мощностью и проблема не в нём). Штука мощная,
> монструозная и дешёвая, поэтому там экономят на всём подряд, IMHO.Скорее просто не повезло - определенный процент брака есть везде. Детали там типичные для любой MB, да и на чем там экономить? Схема на порядок проще типичной MB. Если их производят на тех же фабриках что и MB, то надежность должна быть выше.
Мой экземпляр отлично работает от обычного usb от десктопа, под полной нагрузкой + разгон 1GHz (рубились в takken 3 в эмуляторе ps1, на 700MHz притормаживает).
>> Кстати спорно. Мне попалась Pi, которая перезагружалась на высоких нагрузках (блок питания
>> был с избыточной мощностью и проблема не в нём). Штука мощная,
>> монструозная и дешёвая, поэтому там экономят на всём подряд, IMHO.
> Скорее просто не повезло - определенный процент брака есть везде. Детали там
> типичные для любой MB, да и на чем там экономить?На питании (судя по симптомам). Может быть стабилизатор с мощностью на грани. Попался слегка бракованый (с мощностью чуть ниже) и всё.
Но вероятно вы правы.
> Мой экземпляр отлично работает от обычного usb от десктопа, под полной нагрузкой
> + разгон 1GHz (рубились в takken 3 в эмуляторе ps1, на
> 700MHz притормаживает).Нехило.
> На питании (судя по симптомам). Может быть стабилизатор с мощностью на грани.У пи все очень безбашенно с питанием. Ну не умеют они это. Они маркетологи, а не инженеры. Питальники они делать не умеют.
> Кстати спорно. Мне попалась Pi, которая перезагружалась на высоких нагрузкахСкорее всего проблемы с перегревом (там все очень плохо с температурными делами) или питальником. На самом деле - и так и сяк. Но этой проблемой не страдают например китайцы, запаявшие нормальный менеджер питания (пачка управляемых импульсных понижаек и прочая).
> Как уже отметили, речь об состоянии системы, а не о интерпретации скрипта.В многозадачке состояние системы всегда может меняться. Ну там часы могут например перевестись за счет NTP. Надо просто быть готовым к этому, в т.ч. и в коде.
> Systemd/udev может изменить право доступа или имя устройства
Может. Но для большинства девайсов это случается только при начальном добавлении или отключении устройства и иных нестандартных случаях. В этот момент программа в любом случае столкнется с исключительной ситуацией. Если там забили на ошибки - ССЗБ.
> или создать динамически генерируемый конфиг
В многозадачке появление файлов параллельно с работой вашей программы - штатная ситуация.
> - все это делает систему менее предсказуемой,
Вы изначально не должны делать допущений о том что ваш процесс или скрипт единственная сущность в многозадачной системе. Фундаментальная ошибка.
> сложнее точно сказать какие будут произведены действия в той или иной ситуации.
Если вам всегда нужно знать все и вся с точностью до бита - лучше не вылезать за пределы PIC-16 и систем уровня DOS.
> Возможно, но не думаю что разница существенна при использовании sh (ash/dash)
Когда их будет десяток - разница может стать заметной. Да и список процессов замусорен лишний раз. Наф-наф-наф.
> для определенных ситуаций/сервисов может быть необходима.
Ну вот у меня этих определенных ситуаций - везде. И я хочу видеть ряд фич системды и на десктопах, и на серверах, и в эмбедовке. А со сказками кому и что должно и нужно - только шиндошс продавать.
> таймаутами, etc), не зависящей от системы инициализации.
Система инициализации имеет очевидные плюсы:
1) Инит всегда запущен. Поэтому находится в нyжном месте, в нужное время, с нужными правами для того чтобы выступить супервизором. Не требуя по экземпляру на каждый процесс.
2) Инит всегда запущен. Не надо делать переинициализацию процесса -> быстрее.
3) Когда процесс инита создает новый процесс для запуска сервиса, у него все карты на руках чтобы в этот момент расставить все параметры. Это наиболее просто и логично. Остальное кривее и сложнее.> и все довольны: не хочешь не используй и единое решение для
> всех дистрибутивов/систем инициализации.Если инит в системе уже есть и запущен - зачем мне чтобы он висел просто так, тогда как мне придется костылить? За всех расписываться не надо.
> А проекты типа busybox могли бы включить облегченную реализацию.
А работало бы не лучше чем сейчас. Инициализация большой проги на старт каждого процесса - занимала бы времени. И куда девать результат работы? Инит есть всегда. А остальное - как повезет. Да и смысла запускать мегапрогу, чтобы очередной скрипткид тихо спустил в трэш коды возврата и вывод проги, как обычно?
> То есть вы считаете что lockup видео драйвера происходит исключительно на дискретных видиoкартах?
Я считаю что lockup видео на сервере - 100500-й приоритет. У многих серверов видео вообще может не быть. Или оно не имеет ничего общего с "видеокартой". А т.к. почти все сервера не используют видео - вероятность проблем с ним около ноля. А если чипсет или проц помереть надумал - софт не поможет.
> поймал регрессию на радеонах ведущую к lockup в kernel-4.1.
Да я такого ловил кучами. Последнее время - на SI. Но вы знаете, на большинстве серверов не будет даже вгружен модуль радеона. Да и lockup GPU клинит гyйные программы. Драйвер перестает выполнять запросы иксов и проч. Их клинит. Те кто им запросы кидал, по цепочке тоже клинятся. А ядро работает. Чтение с диска не страдает. И работа с сетью. На такую машину можно зайти по ssh, etc. Сервер вообще не заметит такое.
> При том как на дискретной, так и на чипсете.
А они даже не пытались быть надежными. Которые хоть капельку пытались - там видеовыхода нет порой :). Зато память c ECC. И стоят как два моих десктопа. А это - обычный ширпотреб.
> А как же - "У меня логика простая: система или делает то
> что должна, или уходит в ребут и восстанавливается в известное,Так это логика беспилотной эмбедовки. Для сервера такая логика может быть, а может и не быть применима. Смотря что за сервер. Если в продакшне - может быть вариантом, на dev-машине - плохая идея. Ваши взгляды сдвинуты в сторону -dev, имхо. Для продакшна же главное - работа.
> Любое дублирование существенно повышает шансы на безотказность.
А также увеличивает цену, потребление энергии, занимаемое место, etc.
> Можно взять три ненадежных элемента - ПК, сотовый модем с gpio, RBPi
> (ждущий email с паролем для ресета). И получить достаточно безотказный удаленный ресет.Можно. Но есть нюансы на стыке взаимодействий, а также насчет того кто и какой доступ может внепланово получить, например. И система в целом сложнее и дороже.
> продублируют, вплоть до управления со спутника.
Если удорожание оправдывается. А если нет - будет некое компромиссное решение. И да, а хотя-бы и с клацанием релюхой прямо с одноплатника иной раз.
> Всякие кocмoнавты для таких случаев берут несколько девайсов
Так и цены на это все - космические!
> ИМХО пока ядро живо, должны использоваться менее агрессивные средства (типа killall),
Ну вот прилетел мощный EMI (молния рядом шибанула, etc). Или ESD. RAM местами зaгaдилась, например - на шину навелось достаточно для переворота битов. Откуда известно что и где испорчено? При сбросе эти факторы выпадают из уравнения.
> а вачдог должен сработать только при зависании ядра либо при глухом (killall
> и рестарт не помогают) зависании служб/драйверов необходимых для удаленного управления.Системдой можно и такое сделать в два счета. Можно просто рестартить процесс, не отсигналивший свой вачдог. Ребут безглючнее, но потеря state и больше даунтайм.
> Нет, в поставленной вами задачи - мы выносим критическую задачу на МК
> (таймер и gpio), а не критическую (веб морда) на Pi-образный девайс.Подгон решения под ответ. То что делал Pi-образный вполне может быть ВАЖНОЙ частью задачи. И насколько это "менее" критично по мнению юзерей - варьируется в разных задачах.
> Возможно, но когда я пытался управлять насосом с выделенного ПК
ARMообразные железяки набирают аптайм... я видел около года. И как ни странно, типовая причина сброса аптайма - отключка питания по разным поводам. И при правильном подходе - сильно надежнее дешевых писюков. У большинства одноплатников btw, электролитов нет. Вспухать нечему.
> Это совершенно другая задача, и как правило менее критичная,
Очень зависит от того что за железка. Зачем юзерю например система наблюдения, которая картинку не кажет?
> чем управление всякой автоматикой. Да и она в основном решается дублированием.
Опять же - требования по надежности и последствия бывают разными. Ну а если можно подстраховаться малой ценой (e.g. вачдогование важных процессов с минимальным кодингом фичи) - я только за.
> Я просто предложил наиболее оптимальное решение для озвученной вами задачи.
При том у вас какие-то специфичные понятия об оптимальности и о том чего хотят юзеры. Не учитывающие некие факторы и игнорящие чужой опыт.
> выбирай для каждой задачи свое наиболее подходящее решение, а не одно универсальное.
Ну да. И тем не менее, у системды много настроек и поэтому он полезен много где. Не серебряная пуля, но подыграть системщику лишний раз - может.
> Все универсальное (компромиссное) будет по определению хуже специализированного
Делать ASIC под каждую задачу - долго и дорого.
> Как не крути, а что на PC что на pi-like - миллионы строк кода,
Тем не менее, этот код может работать достаточно надежно. Месяцы и даже годы. Но да, там больше потенциал для сбоев и багов и это не стоит забывать.
> ненадежная загрузка (карта памяти или винт).
Карты памяти - достаточно надежны, если от нормальных производителей и не мучать записью. Но можно и набортную флеху использовать. Даже левая фирмварь контроллера карты из уравнения выпадет. Но другие грабли добавятся (начальная прошивка станет отдельным приключением, etc).
> по железу (проще система питания, проще система охлаждения, меньше разъемов),
Главное - токи на порядок ниже и электролитов мало или нет. Одноплатники не умирают от опухания электролитов через год-два, в отличие от ПКшек.
> но ИМХО pi-like будет надежнее в 2-3 раза, а МК - на порядок или два.
Я бы сказал что может быть и на порядок: токи адекватнее, электролитов нет. Step-down на мегагерц-два (типовой IC power manager-а) доволен условно-вечной керамикой на пару десятков мкф. А в писюке проц кушает много, а керамика денег стоит. Паять СТОЛЬКО керамики всех давит жаба. А электролиты в сильноточной цепи - через пару лет дохнут. Как раз после срока гарантии.
>> Как уже отметили, речь об состоянии системы, а не о интерпретации скрипта.
> В многозадачке состояние системы всегда может меняться. Ну там часы могут например
> перевестись за счет NTP. Надо просто быть готовым к этому, в
> т.ч. и в коде.NTP — это понятно, неизбежное зло, вызванная аппаратными особенностями компьютеров. Да и вообще, это очень предсказуемая проблема, о которой в курсе каждый уважающий себя программист. А вот когда ты хочешь сделать для себя свой собственный whitelist-список устройств, а выясняется, что твоими cgroup-ами управляют извне — это уже лишний повод для проблем. Все extra features должны быть отключены по умолчанию и, желательно, должны находиться в отдельных бинариев, без которых «базовый функционал успешно функционирует».
>> Systemd/udev может изменить право доступа или имя устройства
> Может. Но для большинства девайсов это случается только при начальном добавлении или
> отключении устройства и иных нестандартных случаях. В этот момент программа в
> любом случае столкнется с исключительной ситуацией. Если там забили на ошибки
> - ССЗБ.Опять же. Чем больше поводов для ошибки создаётся, тем больше из них приведут к fail-у в production-е. Если какой-то инструмент не нужен, то он должен быть отключен. Если, например, у меня контейнер, где все устройства статичны, то зачем мне там udev? Да и dbus там нужен чуть чаще, чем никогда. Лишь источники неполадок.
>> или создать динамически генерируемый конфиг
> В многозадачке появление файлов параллельно с работой вашей программы - штатная ситуация.Если я правильно понял комментатора, то речь не именно про появление файла и коллизию, а про неожиданное изменение содержимого, что в свою очередь затрудняет не работу программы, а работу сисадмина, который держал у себя в голове одно содержимое, а там на самом деле уже другое.
>> - все это делает систему менее предсказуемой,
> Вы изначально не должны делать допущений о том что ваш процесс или
> скрипт единственная сущность в многозадачной системе. Фундаментальная ошибка.Он вроде и не делал таких допущений.
>> сложнее точно сказать какие будут произведены действия в той или иной ситуации.
> Если вам всегда нужно знать все и вся с точностью до бита
> - лучше не вылезать за пределы PIC-16 и систем уровня DOS.Всегда должна быть возможность легко диагностировать проблемы.
>> Возможно, но не думаю что разница существенна при использовании sh (ash/dash)
> Когда их будет десяток - разница может стать заметной. Да и список
> процессов замусорен лишний раз. Наф-наф-наф.Не хотелось бы противоречить позиции Mihail-а, но всё-таки честности ради обязан сказать, что согласен: мусор вроде while true — это скорее workaround, а не production-ready решение. Как раз благодаря снижению предсказуемости :)
>> для определенных ситуаций/сервисов может быть необходима.
> Ну вот у меня этих определенных ситуаций - везде. И я хочу
> видеть ряд фич системды и на десктопах, и на серверах, и
> в эмбедовке.Мне кажется, что это связано с неиспользованием других вещей, которые можно подцепить к тому же OpenRC
>> таймаутами, etc), не зависящей от системы инициализации.
> Система инициализации имеет очевидные плюсы:
> 1) Инит всегда запущен. Поэтому находится в нyжном месте, в нужное время,
> с нужными правами для того чтобы выступить супервизором. Не требуя по
> экземпляру на каждый процесс.Что мешает не-init-у быть запущенным с нужными правами?
> 2) Инит всегда запущен.
Что мешает не-init-у быть всегда запущенным, после того, как init его запустит?
> Не надо делать переинициализацию процесса -> быстрее.
Какую переинициализацию процесса?
> 3) Когда процесс инита создает новый процесс для запуска сервиса, у него
> все карты на руках чтобы в этот момент расставить все параметры.Что мешает не-init-у иметь доступ ко всему необходимому?
> Это наиболее просто и логично. Остальное кривее и сложнее.
IMHO, как раз наиболее логично и красиво, когда init — это init, а обвязка — это обвязка.
>> и все довольны: не хочешь не используй и единое решение для
>> всех дистрибутивов/систем инициализации.
> Если инит в системе уже есть и запущен - зачем мне чтобы
> он висел просто так, тогда как мне придется костылить? За всех
> расписываться не надо.Не понял, что вы хотели сказать. Хотели сказать, что init выполняет слишком мало функций и поэтому его нужно дополнительно нагрузить? Зачем? IMHO, наоборот, он должен делать как можно меньше, а всё остальное — это отдельные штуки.
>> А проекты типа busybox могли бы включить облегченную реализацию.
> А работало бы не лучше чем сейчас. Инициализация большой проги на старт
> каждого процесса - занимала бы времени. И куда девать результат работы?
> Инит есть всегда. А остальное - как повезет.Когда я говорил, что у меня systemd не стартовал в контейнере, один из случаев был таким:
После запуска в контейнере были толко два процесса: systemd и journalctl. Оба процесса жрали 100% CPU. Чтобы продолжить загрузку достаточно было убить через SIGKILL «journald».
> Да и смысла
> запускать мегапрогу, чтобы очередной скрипткид тихо спустил в трэш коды возврата
> и вывод проги, как обычно?Если не хочется скрипты — можно их не использовать. Вполне можно сделать какую вам угодно обвеску вокруг init-а, который умеет работать и с unit-файлами и со всем остальным. Только пачкой отдельных процессов, которые могут легко друг без друга работать (и не требовать перекомпиляции для этого с принципиальным отключением какой-то feature). Например должна быть возможность использовать syslog-ng без journald.
>[оверквотинг удален]
> - вероятность проблем с ним около ноля. А если чипсет или
> проц помереть надумал - софт не поможет.
>> поймал регрессию на радеонах ведущую к lockup в kernel-4.1.
> Да я такого ловил кучами. Последнее время - на SI. Но вы
> знаете, на большинстве серверов не будет даже вгружен модуль радеона. Да
> и lockup GPU клинит гyйные программы. Драйвер перестает выполнять запросы иксов
> и проч. Их клинит. Те кто им запросы кидал, по цепочке
> тоже клинятся. А ядро работает. Чтение с диска не страдает. И
> работа с сетью. На такую машину можно зайти по ssh, etc.
> Сервер вообще не заметит такое.Часто на первое время серверы делают на базе midtower-ов из-за временного недостатка денег. А там может стоять видеокарта, которая даже при обычной печате логов на экран (без framebuffer) вполне может перегреться, если что-то произошло с радиатором или вентилятором.
>> А как же - "У меня логика простая: система или делает то
>> что должна, или уходит в ребут и восстанавливается в известное,
> Так это логика беспилотной эмбедовки. Для сервера такая логика может быть, а
> может и не быть применима. Смотря что за сервер. Если в
> продакшне - может быть вариантом, на dev-машине - плохая идея. Ваши
> взгляды сдвинуты в сторону -dev, имхо. Для продакшна же главное -
> работа.У меня есть серверы, где для production-а важнее отсутствие утечки информации, чем работоспособность. Поэтому причины отказа сервиса нужно диагностировать до перезагрузки. Если хацкер будет ломать ядро, то авто-перезагрузка даст ему неплохие возможности, ибо в случае ошибки можно будет продолжить работу.
>> ИМХО пока ядро живо, должны использоваться менее агрессивные средства (типа killall),
> Ну вот прилетел мощный EMI (молния рядом шибанула, etc). Или ESD. RAM
> местами зaгaдилась, например - на шину навелось достаточно для переворота битов.
> Откуда известно что и где испорчено? При сбросе эти факторы выпадают
> из уравнения.Вот только до перезагрузки хотелось бы понять из-за чего возникла проблема. А после перезагрузки уже нéчего диагностировать, кроме логов.
>> Нет, в поставленной вами задачи - мы выносим критическую задачу на МК
>> (таймер и gpio), а не критическую (веб морда) на Pi-образный девайс.
> Подгон решения под ответ. То что делал Pi-образный вполне может быть ВАЖНОЙ
> частью задачи. И насколько это "менее" критично по мнению юзерей -
> варьируется в разных задачах.
>> Возможно, но когда я пытался управлять насосом с выделенного ПК
> ARMообразные железяки набирают аптайм... я видел около года. И как ни странно,
> типовая причина сброса аптайма - отключка питания по разным поводам. И
> при правильном подходе - сильно надежнее дешевых писюков. У большинства одноплатников
> btw, электролитов нет. Вспухать нечему.[offtop]Каждый раз не сразу въезжаю, что под ARM-ообразными железками вы понимаете RPi-like, а не STM32-like (ибо тот тоже ARM).[/offtop]
>> Это совершенно другая задача, и как правило менее критичная,
> Очень зависит от того что за железка. Зачем юзерю например система наблюдения,
> которая картинку не кажет?Если нужно в realtime казать картинку, то лучше использовать готовые системы видеонаблюдения, IMHO. Не очень понятно зачем делать своё кастомное. Единственный ответ в моей голова — работа в компании, специализирующейся на системах видеонаблюдения. Если так, то они, скорее всего, делают крупносерийные железки. А там есть смысл искать более дешёвые решения, чем RPi-like (если такие найдутся).
>> Я просто предложил наиболее оптимальное решение для озвученной вами задачи.
> При том у вас какие-то специфичные понятия об оптимальности и о том
> чего хотят юзеры. Не учитывающие некие факторы и игнорящие чужой опыт.Мне кажется, тут этот процесс взаимный :). Для того и беседуем, чтобы понять чужой опыт.
>> выбирай для каждой задачи свое наиболее подходящее решение, а не одно универсальное.
> Ну да. И тем не менее, у системды много настроек и поэтому
> он полезен много где. Не серебряная пуля, но подыграть системщику лишний
> раз - может.Одна из его проблем как раз в том, что у него слишком много настроек (в нём самом, а не поддержка внешнего решения, выполняющего дополнительные функции), IMHO.
>> Как не крути, а что на PC что на pi-like - миллионы строк кода,
> Тем не менее, этот код может работать достаточно надежно. Месяцы и даже
> годы. Но да, там больше потенциал для сбоев и багов и
> это не стоит забывать.Но МК всё равно будет надёжнее, IMHO. Хватает ли ресурсов (как и в МК, так и просто человекочасов) — это конечно вопрос. Но если говорить про надёжность, то у RPi гораздо больше точек для отказа, IMHO. Хотя спроектировать собственную плату и написать прошивку — тоже те ещё задачки, даже если задача простая.
Хотелось бы понять насколько по-разному мы мыслим на примере очень простой задачки:
Допустим имеется 20 одинаковых телефонных аппаратов с какими-то неполадками (например, не рабочий экран), однако способные совершать вызовы и обеспечивать двусторонний диалог. Аппараты без кнопок быстрого набора. Стоит задача — необходимо в 20 терминалов (вандалоустойчивый компьютер) установить «кнопку экстренного телефонного вызова технической поддержки». Можно воткнуть в каждый терминал по RPi, напихать туда USB-трубок, запихать на RPi линуху с linphone-ом и при нажатии внешней кнопки вызывать тех. поддержку. А можно просто взять те полудохлые аппараты, и просто туда на базе того же stm32f0 и оптореле сделать автонабиралку номера. Потом растиражировать (распечатать ещё 19 плат и дать мартышке инструкцию по пайке). Какой вариант правильнее? И если никакой из указанных, то тогда какой?
> NTP — это понятно, неизбежное зло, вызванная аппаратными особенностями компьютеров.Это не аппаратные особенности компьютеров, это следствие многозадачности ОС. А факапы - следствие того что некоторые люди мнят что они в системе одни и никто не может часы перевести. А это не так. И это касается всех аспектов работы многозадачки.
> Да и вообще, это очень предсказуемая проблема, о которой в курсе
> каждый уважающий себя программист.Программист или понимает что это многозадачка, состояние которой меняется в множестве закоулков помимо него, или нет. Чего бы вдруг он поймет прo NTP, но прощелкает с открытием файлов или правами - не понятно.
> А вот когда ты хочешь сделать для себя свой собственный whitelist-список
> устройств, а выясняется, что твоими cgroup-ами управляют извне — это
> уже лишний повод для проблем.А как управление cgroups вообще пересекается с белым списком устройств?
> Все extra features должны быть отключены по умолчанию и, желательно, должны
> находиться в отдельных бинариев, без которых «базовый функционал успешно функционирует».Ну вот и отключайте себе sysfs и procfs в ядре, наздоровье. Вон тут гражданин проверил что без них можно обойтись, если очень захотеть.
> Опять же. Чем больше поводов для ошибки создаётся, тем больше из них
> приведут к fail-у в production-е.Теоретически это так. Практически - все несколько сложнее. Решение задачи ограничено по времени, деньгам и ресурсам и поэтому доводить все до максимально оптимзированного ASIC с минимально-возможным числом транзисторов у меня может и не быть ресурсов и времени и это может быть нецелесообразно по стоимости. Поэтому сказать что systemd мне не требуется - я не готов.
> Если какой-то инструмент не нужен, то он должен быть отключен.
Если на то пошло - можно обойтись без библиотек. И без ядра. Написать все самому, в фирмваре делающей прямой доступ к железу, и телемаркет. Хотя лучше сразу ASIC максимально оптимизированный запилить. Но вот правда есть нюансы.
> Если, например, у меня контейнер, где все устройства статичны, то зачем мне там udev?
В именно контейнере - может быть и ни к чему. С другой стороны, по логике вещей в контейнер должно быть можно пробросить девайсы и не только статично, а то что ваш юзкейс принципально лучше других или наиболее типовой - бабушка надвое сказала.
> Да и dbus там нужен чуть чаще, чем никогда. Лишь источники неполадок.
Я даже и не могу вспомнить на моей памяти когда d-bus у меня неполадки хоть в чем-то вызывал.
> и коллизию, а про неожиданное изменение содержимого, что в свою очередь
> затрудняет не работу программы, а работу сисадмина, который держал у себя
> в голове одно содержимое, а там на самом деле уже другое.Админ имхо на себя много брал, делая такие допущения в многозадачке. С такими запросами - в MSDOS, имхо.
> Он вроде и не делал таких допущений.
Тогда я не понимаю что ему не нравится. Изменение файлов по ходу работы системы - обычное дело для многозадачки.
> Всегда должна быть возможность легко диагностировать проблемы.
И кроме всего прочего sysv init этому совсем не соответствовал: там вообще нет никакого boot time дебага, логинг по принципу "насколько не лень майнтайнеру", отсутствие реакции на коды возврата в большинстве случаев и прочая. И потенциально куски сложной логики в неожиданных местах.
> Не хотелось бы противоречить позиции Mihail-а, но всё-таки честности
> ради обязан сказать, что согласен: мусор вроде while true — это скорее workaround,Это вообще источник кучи проблем. А поттеринг обрабатывает массу проблемных ситуаций. Иногда случающихся в продакшновых системах. И совсем не радующих потом.
> которые можно подцепить к тому же OpenRC
Не вижу какие из моих проблем OpenRC вообще решал бы и делал это лучше чем конкуренты типа системды. И куча скриптятины, писаной левой пяткой по укурке - довольно сильно снижает предсказуемость системы, имхо.
> Что мешает не-init-у быть запущенным с нужными правами?
То что все это - отдельные действия. Требующие весьма отдельной обработки и аккуратности, а потом еще и сброса прав. Потому как фигарить под полновесным рутом в программе как-то ну совсем не комильфо. И в результате это еще туева хуча системного кода. В каждой проге.
ИМХО лучше выгрузить это в systemd и потом реюзать его код. Из всех программ. Парой строк конфига.
> Что мешает не-init-у быть всегда запущенным, после того, как init его запустит?
Наверное то, что если он помрет - супервизить его должен был кто-нибудь другой. Инит отлично годится на эту роль: всегда есть, имеет нужные права, знает что запускает.
> Какую переинициализацию процесса?
Ну там форки лишние, etc.
> Что мешает не-init-у иметь доступ ко всему необходимому?
То что на все это надо дофига прав, эти права в run time обычно не требуются, а кодинг половины системной механики по деланию всего этого и сброса прав - очень отдельное развлечение, которым я не хочу в каждой первой программе заниматься.
> IMHO, как раз наиболее логично и красиво, когда init — это init,
> а обвязка — это обвязка.А на мой вкус - кое-кто игнорил кучу long-standing проблем программирования и администрирования. И потом подобным кадрам довольно жестко объяснили что они в этом неправы.
> Не понял, что вы хотели сказать. Хотели сказать, что init выполняет слишком
> мало функций и поэтому его нужно дополнительно нагрузить? Зачем?Потому что он висит с полными правами. Всегда. И порождает остальные процессы. И поэтому ему проще и логичнее всего делать вещи типа супервизинга процессов. Даже sysv init это умеет малость. Но в таком виде, что толку с этого - ноль.
> IMHO, наоборот, он должен делать как можно меньше, а всё остальное — это
> отдельные штуки.Я как админ и програмер на изветсном месте вертел перспективу кодить или скриптить базовые системные операции на каждую первую оказию.
> После запуска в контейнере были толко два процесса: systemd и journalctl. Оба
> процесса жрали 100% CPU. Чтобы продолжить загрузку достаточно было убить через SIGKILL «journald».Ну как бы баг. И с технической точки зрения:
- Systemd сам по себе может ловить как раз взвис сервиса на старте и проверять фактическую живость. Если это не было настроено - это к админу. А если не сработало - поцтеру в багтрекер.
- Взвис journalctl не является правильным поведением, имхо. Это некий bug.Но знаете, вон например у дебианщиков - скрипты не могли нормально остановить нжинкс одно время. Вообще заваливая деинсталл пакета. Но я что-то не помню жутких воплей что скрипты - это фи.
> Если не хочется скрипты — можно их не использовать. Вполне можно сделать
> какую вам угодно обвеску вокруг init-а,Ну вот в systemd как-то так и есть: я буду звать скрипты только когда это реально требуется.
> Например должна быть возможность использовать syslog-ng без journald.
А у вас разве кто-то занимал? Или с чего они вдруг вам "должны"?
> логов на экран (без framebuffer) вполне может перегреться, если что-то произошло
> с радиатором или вентилятором.ИМХО это синтетическая и кривая ситуация и тут надо не софту предъявлять, а тем кто таким занимается. Ну ставили бы ARMовскую платку за тридцать баксов, она при всем желании не перегреется и без вентиля. В миди-тауэре можно целый кластер собрать. А то что кто-то набрал на помойке глючных писюков - его проблемы. Желать чего-то от глючного железа вообще оксюморон.
> У меня есть серверы, где для production-а важнее отсутствие утечки информации, чем
> работоспособность. Поэтому причины отказа сервиса нужно диагностировать до перезагрузки.А у многих других людей другие приоритеты и случаи. ИМХО дефолты должны делаться так чтобы покрывать наиболее типовые юзкейсы.
> Если хацкер будет ломать ядро, то авто-перезагрузка даст ему неплохие возможности,
> ибо в случае ошибки можно будет продолжить работу.Потенциально есть такие грабли. Но что и где приоритетнее... вот у меня на железке сети может не быть совсем. И хацкеров. А вот зависон - это грабли.
> Вот только до перезагрузки хотелось бы понять из-за чего возникла проблема. А
> после перезагрузки уже нéчего диагностировать, кроме логов.Можно попробовать core dump собирать. Но коредампы в продакшне - еще одна мина замедленного действия.
> вы понимаете RPi-like, а не STM32-like (ибо тот тоже ARM).[/offtop]
Ну да. В основном штуки на allwinner. Несмотря на то что там автомобиль собирают по ходу гонки, core parts линя обычно оправдывают ожидания и не подводят.
На самом деле я видел всего 2 deadlock за все время. Один - в вендырском ядре 3.4, эзернет. Это known issue для тех кто в теме и одна из причн антипатий к вендырским SDK. Китайские дрова - гуано. Второй был судя по всему race condition когда у usb-девайса были проблемы с кабелем и девайс подключался-отключался с максимальной скоростью. В конце концов, через 10 минут странностей ядро Linux таки поймало deadlock. Через 10 секунд вачдог все это срубил, подтвердив что я немного научился готовить этих кошек.
> Если нужно в realtime казать картинку, то лучше использовать готовые системы видеонаблюдения,
Они или не умеют анонсы в желаемом виде, или льют видео на хрен знает какие сервисы, и вообще достаточно дубовые и дорогие штуки. Мне они не нравятся.
> моей голова — работа в компании, специализирующейся на системах видеонаблюдения.
На самом деле конкретно вот такие хотелки - больше для себя. В перспективе я научусь делать нечто типа core для умного дома. Кроме всего прочего и потому, что мне самому надо несколько юнитов такого добра. Быть сапожником без сапог надоело, а найти опенсорсное и не западлоидизированное, по симпатичной цене... ну я не в курсе таких опций.
> есть смысл искать более дешёвые решения, чем RPi-like (если такие найдутся).
Сильно дешевле - некуда. При малейшем намеке на конективити это всяко SoC с линухом. Да и интерфейсы типа два притопа, три прихлопа - лишь Зенкову нравятся. А я не фанат такого. И остальные юзеры тоже.
> Для того и беседуем, чтобы понять чужой опыт.
Вообще, да. Но многие ваши сценарии кажутся мне странными.
> Одна из его проблем как раз в том, что у него слишком много настроек
С другой стороны, все это более-менее оттестирует толпа народа. И это обезглючат. В отличие от глюченных скриптов и черти-каких конфигураций, работающих абы как.
> (в нём самом, а не поддержка внешнего решения, выполняющего
> дополнительные функции), IMHO.Обезглючить массово применяемое решение проще чем 100500 кастомных конфиг. Поэтому я могу поверить что системд будет относительно стабильным. А вот абы какие кастомные конфиги из скриптов, соплей и скотча, где часто не проверяют не то что таймауты но и коды возврата...
> Но МК всё равно будет надёжнее, IMHO.
Зависит от конкреитки. Но вообще в целом потенциал к этому у МК есть.
> если говорить про надёжность, то у RPi гораздо больше точек для отказа, IMHO.
Но сильно меньше чем в писюке. И я не люблю Pi - они неважные инженеры. Но есть много иных модулей и одноплатников.
> Хотя спроектировать собственную плату и написать прошивку — тоже
> те ещё задачки, даже если задача простая.Пойнт модулей и одноплатников как раз в том что сам такую штуку проектировать слегка задолбаешься, а когда грабли обпрыгали другие - уже ничего так, нормальненько :)
Про телефоны - относительно длинно, см part 2.
> Хотелось бы понять насколько по-разному мы мыслим на примере очень простой задачки:Окей.
[....]
> мартышке инструкцию по пайке). Какой вариант правильнее? И если никакой из
> указанных, то тогда какой?Ответ не такой очевидный как может показаться. Есть нюансы.
1) Если это проектирование терминала с экраном, с ноля - я бы на одноплатнике ВСЕ и делал. Весь терминал. Прицепить дисплей и точ к одноплатнику - то что доктор прописал. Планшет - оно и есть, только корпус иной и интерфейсы покоцаны. Если этому терминалу по роду деятельности всяко надо модем, и там уже есть одноплатник - то логично и голосовую поддержку через то что есть делать, имхо. Прямо в UI впилить еще одну кнопку.
Если надо именно тираж, это может быть как-то так: core терминала - процессорный модуль "как одноплатник, но без обвязки". Под него - ответка: task-специфичная low-tech борда 1-2 слоя, делаемая локально на ближайшей фабе. На ней развести выход на дисплей и точскрин, аналоговую часть и специфичные для задачи ифейсы. Модуль модема. И что там еще. Будет культурно, правильно и ничего лишнего. С проектированием борды придется немного повозиться, отрисовав в CAD ответку под модуль, но это как раз примерно на уровне платы с STM32. Аналог - взять или SoC'овский (залет на гейтование данных в модем и нестандартные приключения) или модуля модема (все хардварно, но SoC не сможет влиять на происходящее и про веще типа VoIP без костылей придется забыть).
Итого - на daughterboard модуль модема, модуль CPU core, аналог и обвязка. Все реально hitech вещи - в самих модулях, а daughterboard тривиальный, 1-2 слоя, с минимальными требованиями. Пойнт модулей: можно сделать простую low-tech плату с ответкой, не попадая на проектирование сложной и капризной многослойки.
2) Вообще-то зависит от пожеланий к тому как все это должно работать и какие фичи хотят. Ну то-есть может захотеться, например, VoIP. Он дешевле и вообще, интернет можно по wi-fi или эзернет шнурку утащить, отделавшись от сотового модема совсем. Насколько я знаю, колонны в метро так сделаны: хотя снаружи лишь пара кнопок, внутрях там wi-fi роутер, и оно по VoIP связывается с диспетчерским центром. На мк делать VoIP я 100% не буду. Я себе не враг. ЧСХ я не видел особых предъяв по части работы этих колонн...
3) Телефоны. Это грабли!!! Купить 20 телефонов с одинаковой неисправностью - сложно. А если потом надо еще 20 таких терминалов - упс! Не воспроизводимое решение. К тому же, на диагностику этого дepьма придется убить кучу времени, и вы не сможете хорошо продиагностировать этот крап. Надежность телефонов - никакая. Вы не знаете почему они реально умерли и сколько проживут. Они не заточены на работу 24/7 с зарядником. Насколько облажается менеджер питания и логика заряда у именно этой модели - узнаете потестировав в продакшне? :) По нормальному сие делается на индустриальном модуле модема. Там все ключевые сигналы вынуты на контактные площадки. Ну там микрофон, спикер, или, например, сигнал "power on". Так что если модуль (в коем несколько мегов фирмвари сомнительной глючности с GSM стеком!) повиснет и его антизависаторы лоханутся (а вы знаете как все это сделано у выбранного телефона или модуля?) - софт по крайней мере может черeз GPIO грубо передернуть. Дерг через GPIO входа "power on" модуля модема - аналог зажатия "power" на телефоне: тот же сигнал, тому же чипу менеджера питания. Только не надо курочать ничего. Манагер питания модуля - полностью выключит "цифру" модуля, и включит заново. Это деглюкавит модуль из любого состояния, что важно на автопилоте. А вот что вы будете с повисшим телефоном делать - это вопрос! У некоторых есть power on на разъеме, у некоторых нет. Разъемы и сигналы бывают разные.
4) Насчет МК. На МК я бы подумал сделать если готовая система - уже есть. И хочется к ней именно минимальный довесок, в уже готовую систему, от которой зависеть совсем не хочется. Тогда я бы взял МК и модуль модема. Ну и на плате был бы МК, модем и аналог разведенный с модуля модема на динамик и микрофон, etc. Но тут есть некоторые не очень приятные грабли: ну ок, а как вы, допустим, номер на который звонок будете настраивать? Чтобы легитимный юзер мог номер настроить как-то по простому для себя, а никто левый не мог настройки сбить.
> А ядро будет работать, если выставить "n" по всем опциям в конфиге?Не знаю, но зачем-то allnoconfig держат. Впрочем, Вы передёрнули: два пункта противопоставили "всем опциям".
PS: Ваше #85 удалено на основании п. 4 http://wiki.opennet.ru/ForumHelp -- запомните, ламер есть агрессивный чайник, и лучше не хамите людям вообще (и уж тем более тем, до опыта которых Вашему крайне далеко).
Опыт без мозгов = типичный systemd-хейтер, что мы и видели выше - несёт ахинею и не краснеет.
> systemd тянет в себя все подряд и зачастую то, что к системе
> инициализации не имеет никакого отношения.Во первых сложно провести четкую грань. Ну вот смотри, если системный вачдог дергается системдой а тот в свою очередь является софтварным вачдогом для важных процессов, получается расшаривание вачдога на всю толпу. При том - логично устроенное и как-то так
это и должно быть сделано. Ну и лично я рад что смогу без большого гемора запиливать железки под автопилот, а системд - сгрузит с меня часть рутины. Я не больно хочу кодить логику шаринга вачдога и супервизинга процессов сам. А у системды это довольно логично сделано. Ну да, мой сервис будет требовать системд. Но там один фиг туева хуча linux-специфичных вызовов, характерных для новых ядер, а работает оно в готовой железке, где никакой генты не будет даже в проекте - так что никто ничего с этого не теряет :)> Вдобавок дублирует и завязывает на себя
> то, что уже было написано, отлажено и работало без него.Не вижу где была написана логика вачдогования. Не вижу обработки ошибок и логинга статусов в горьбатом скриптошите. Не вижу нормального управления процессами, типа выставления шедулеров, приоритетов, урезания прав и прочая. А еще оно может логгить... ну допустим в kmsg. Удобно, если ничего кроме него вообще нет. Это можно было сделать на соплях и скотче, но т.к. из скрипта сискол в лоб дернуть не того - получался страх и ужас. В kmsg тоже запись из скриптов работает криво. А вот системд можно попросить дернуть нужные сисколы парой директив конфига. Это удобно.
> Если бы systemd позиционировал себя как отдельная ОС (типа как android), то
> критики было бы на порядок меньше.Он не ОС. Он - системный менеджер. Берет на себя типовую системную рутину. В том числе - старт процессов. А также их вачдогование, трекинг зависимостей, рестарты, расстановку приоритетов и прочая. И это таки удобно, хоть вы тут полопайтесь все.
> Ядро включает в себя только то, что характерно для ядер и что
> нужно для работы с железом.Оно включает в себя довольно много чего...
1) Оно нынче может запускать ядерные треды.
2) Есть всякие там nfs и даже httpd в ядре.
3) Куча всяких весьма опциональных вещей типа профилирования и отладки. Хомяк может и без perf обойтись. И Kdb ему ни к чему. А вот разработчикам - удобно.
4) В дефолтной сборке дистра over 9000 алгоритмов сжатия, шифрования и чексумм. Совсем не факт что лично тебе они нужны все.
5) Там есть например вывод графики на экран. Опциональный и по сильно некоторым случаям. Но все-таки.
6) Всякая хрень типа FUSE и прочих "драйверов символьных устройств в userspace". Так что те кто бредил по микроядрам - давно могут писать половину дров в режиме пользователя, если им это так уж сильно надо.Половину ессно можно обрубить, если сильно хочется. Ну так и в системд много что обрубается, если что. Скажем journald - опция. А то что майнтайнеры дистра могут считать по своему... так они для ядра и остальных программ тоже по своему считают.
> При этом оно имеет гибкую систему
> конфигурации и может оставаться работоспособным в минимальной конфигурации.Если задаться целью - systemd можно прилично обрубить. Ну как и линевое ядро примерно. Скажем я ему журналд оборвал в одной из ситуаций. Он логит в kmsg. Просто потому что я хочу "почти readonly" FS для rootfs.
> Излишней завязки user space за какие-то сложные подсистемы ядра тоже не наблюдается.
#define "излишней завязки"?
> Большая часть подсистем и драйверов развиваются отдельными группами вне ядра
А это у них довольно красиво получилось. Но для системды такое оверкилл. Это для совсем больших проектов надо. Системд не настолько монстр чтобы его ТАК пилить на части.
> (то есть фактически являются отдельными проектами)
Это и так и не так. Они не отдельные, в том плане что должны утрясать интерфейсы между собой. Но отдельные в том плане что обычно делается pull отдельной фичи и эта фича достаточно атомарная по смыслу.
> позволяет искать и внедрять новые конкурирующие решения, не ломая при этом старых.
Тем не менее, иногда вытряхивают и старый мусор. Ну вон поддержку i386, например. Или вон renesas в два счета пошел в пень, когда код стало некому писать.
> 2) [...] и даже httpd в ядре.Это кто? khttpd давно выпинали и починили где надобно, TUX* в 4.x будто тоже не наблюдаю...
> Во первых сложно провести четкую грань.Согласен.
> Ну вот смотри, если системный вачдог
> дергается системдой а тот в свою очередь является софтварным вачдогом для
> важных процессов, получается расшаривание вачдога на всю толпу. При том -
> логично устроенное и как-то так
> это и должно быть сделано.Я далек от подобных задач и мне не понятно - для чего вообще нужно расшаривать вачдога, ведь задача вачдога - перезапустить систему, если она впала в ступор (то есть это либо аппаратный сбой, либо сбой на драйверов). Причем тут пользовательские процессы?
> сделано. Ну да, мой сервис будет требовать системд. Но там один
> фиг туева хуча linux-специфичных вызовов, характерных для новых ядер, а работает
> оно в готовой железке, где никакой генты не будет даже в
> проекте - так что никто ничего с этого не теряет :)В вашей ситуации - да, никто ничего с этого не теряет. Но допустим, разработчики Xorg решили использовать вачдог от systemd. Соответственно без systemd Xorg работать не будет. Получится, что для работы с другими init системами, в Xorg все равно придется добавить свой вачдог - кодовая база Xorg станет сложнее (поддержка вачдог от systemd + свой вачдог).
Есть второй вариант - каждая система инициализации пилит свой вачдог. Для Xorg приходится писать поддержу n-ого колличества вачдогов.
Правильный вариант (ИМХО): вачдог, не зависящий от конкретной системы инициализации, но умеющий использовать особенности различных систем инициализации (с возможностью их отключения на стадии компиляции).
>[оверквотинг удален]
>> то, что уже было написано, отлажено и работало без него.
> Не вижу где была написана логика вачдогования. Не вижу обработки ошибок и
> логинга статусов в горьбатом скриптошите. Не вижу нормального управления процессами, типа
> выставления шедулеров, приоритетов, урезания прав и прочая. А еще оно может
> логгить... ну допустим в kmsg. Удобно, если ничего кроме него вообще
> нет. Это можно было сделать на соплях и скотче, но т.к.
> из скрипта сискол в лоб дернуть не того - получался страх
> и ужас. В kmsg тоже запись из скриптов работает криво. А
> вот системд можно попросить дернуть нужные сисколы парой директив конфига. Это
> удобно.Возможно, но нужно это далеко не всегда. Мне лично проще отладить скрипт 15-20 строк, чем изучать поведение каждой опции и боятся что оно может сработать не совсем так как я предполагаю (или что поведение по-умолчанию будет изменено при апдейте).
>> Если бы systemd позиционировал себя как отдельная ОС (типа как android), то
>> критики было бы на порядок меньше.
> Он не ОС.Еще нет, но с каждой версией это все больше похоже на слова Столмана - "у нас, в проекте GNU, было все, кроме ядра".
> Он - системный менеджер. Берет на себя типовую системную
> рутину.consoled? dhcp-server? ИМХО он уже давно перешагнул грань того, что могло бы называться системным менеджером. Да и само название "системный менеджер" мало ему подходит, так как предполагает управление стандартными блоками системы, а не их замещением и интеграцией в себя.
> В том числе - старт процессов. А также их вачдогование,
> трекинг зависимостей, рестарты, расстановку приоритетов и прочая. И это таки удобно,
> хоть вы тут полопайтесь все.А еще в emacs есть текстовый редактор ;)
> Оно включает в себя довольно много чего...
> 1) Оно нынче может запускать ядерные треды.Куда же без них.
> 2) Есть всякие там nfs
Поддержка монтирования сетевых ФС должна быть на уровне ядра. Тем более, что сервера для них не входят в ядро.
> и даже httpd в ядре.
Не знал. Ссылка есть?
> 3) Куча всяких весьма опциональных вещей типа профилирования и отладки. Хомяк может
> и без perf обойтись. И Kdb ему ни к чему. А
> вот разработчикам - удобно.Без средств отладки не обойтись.
> 4) В дефолтной сборке дистра over 9000 алгоритмов сжатия, шифрования и чексумм.
> Совсем не факт что лично тебе они нужны все.Проблемы дистра, можно выбрать более подходящий дистрибутив (или вариант ядра в нем) либо собрать самому.
> 5) Там есть например вывод графики на экран. Опциональный и по сильно
> некоторым случаям. Но все-таки.Ну видео драйвера тоже работают с железом, да и консоль 80x25 меня лично мало радует.
> 6) Всякая хрень типа FUSE и прочих "драйверов символьных устройств в userspace".
> Так что те кто бредил по микроядрам - давно могут писать
> половину дров в режиме пользователя, если им это так уж сильно
> надо.Притормаживает, но не всегда это критично, постоянно использую - хорошее решение для многих проблем.
> Половину ессно можно обрубить, если сильно хочется. Ну так и в системд
> много что обрубается, если что.Обрубить то можно. Тут претензии другие:
1. невозможность использовать отдельные компоненты в других системах инициализации
2. невозможно использовать в минималистичных (без демонов, d-bus, udev) системах.>> Излишней завязки user space за какие-то сложные подсистемы ядра тоже не наблюдается.
> #define "излишней завязки"?Требования user space софта каких-то дополнительных опций (подсистем) в ядре, без которых можно было и обойтись.
В ядре таких примеров не знаю, а ближайший аналог - в mesa была жесткая завязка за libudev для определения pci id адаптера. К чести разработчиков mesa нужно отметить, что пробыла она там не долго - было добавлено более простое решение - получение необходимой информации напрямую с sysfs.
> А это у них довольно красиво получилось. Но для системды такое оверкилл.
> Это для совсем больших проектов надо. Системд не настолько монстр чтобы
> его ТАК пилить на части.Не соглашусь - если бы его разбить на отдельные проекты, то их наработки проще бы было внедрять (при необходимости) в другие системы инициализации.
>> позволяет искать и внедрять новые конкурирующие решения, не ломая при этом старых.
> Тем не менее, иногда вытряхивают и старый мусор. Ну вон поддержку i386,
> например.Естественно устаревший и не используемый код нужно чистить. Но пока не отлажены новые решения и пока они не докажут свое неоспоримое превосходство, старые решения не должны страдать из-за внедрения новых. Сейчас, например, внедряют nftables, но iptables продолжает полноценно работать.
> она впала в ступор (то есть это либо аппаратный сбой, либо
> сбой на драйверов). Причем тут пользовательские процессы?Наверное, при том что более высокоуровневая логика поведения железки - формируется этими процесами. И если девайс перестанет выполнять свои задачи и потребует к себе внимания человека, это опаньки. Даже если ядро и живое, радости то с этого?
> кодовая база Xorg станет сложнее (поддержка вачдог от systemd + свой вачдог).
А вот это уже не факт. Можно скажем заявить что вот такие апи - минмальная планка. И далее вы эти апи или вывешиваете, или как-то очень отдельно дергаетесь по этому поводу. Ну а что, с DRM/KMS как-то так и сделали. Хорошо получилось, имхо. Вон уже бояздэшники запиливают себе, впопыхах передирая древние версии кода из линя. А если так совсем не делать - были бы ща CP/M и MULTICS.
> Есть второй вариант - каждая система инициализации пилит свой вачдог. Для Xorg
> приходится писать поддержу n-ого колличества вачдогов.На практике обычно никто или не пилит совсем, или юзает нечто запиленное до них. Скриптокидозники предпочитают первый вариант. Я - второй. Ну а вы уже показали ваш джамшут-процесс-менеджмент с while true. Который положит систему если это будет не "transient", а "permanent" сбой. Постоянными рестартами сервиса. Круто будет, когда на вход по ssh и остановку грабледрома придется убить полчаса, потому что система озадачена "важным" занятием - рестартом сервиса по кольцу, прямым курсом, с максимальной скоростью. И вот таких нюансов - есть. В апстарте и системд это сделали нормально. С учетом. В отличие от вашего велосипеда из водопроводных труб.
> умеющий использовать особенности различных систем инициализации (с возможностью их
> отключения на стадии компиляции).Для начала я не уверен что именно иксам как процессу надо вачдог. Ну и с практической точки зрения - вот вы побежите в вашей программе запиливать поддержку Menuet OS? Переписав все на асме, потому что у них так принято. Ну и остальные - так же. Поэтому на практике фичу или совсем дропнут, рассказав что "не очень то и хотелось", как местные скриптокидозники, лечащие что в сферическом вакууме единороги должны cpaть радугой а багов быть вообще не должно. Или возьмут готовую реализацию. А варить вел из водопроводных труб в гараже будут только наиболее ушлые. Я считаю что хорошо когда админ умеет программить... при условии что это не перетекает в идиoтский и контрпродуктивный формат и баранью упертость "а я привык вот так".
> Возможно, но нужно это далеко не всегда.
Зато плохо, когда это нужно а этого нет. Самому писать логику супервизора процессов мне как-то не улыбается.
> Мне лично проще отладить скрипт 15-20 строк,
А мне вот совсем не проще, когда такой шитец не стартует "почему-то". А во всех логах - просто ноль. Системд в этом плане втыкает с отрывом. Он и код возврата запишет, и вывод программы покажет. И даже в /dev/kmsg залоггит, если например ничего другого не доступно в энной ситуации. А из скрипта в kmsg самому логгить - грабледром, скажу я вам. А если например ФС readonly, а экрана принципиально нет - куда еще логгить? Системд почему-то нормально к таким подаркам судьбы относится. Это страновато для шапки, особенно после сказок хейтеров, но все-таки.
> может сработать не совсем так как я предполагаю
Не знаю, на мое нескромное мнение системд сделан довольно логично и ведет себя чаще всего именно так как я ожидаю. И это обычно видится мне логичным и понятным поведением. И уж куда конструктивнее чем местные визги про "нужно не везде", "можно обойтись" и "в ваших программах не должно быть багов!!!111".
> (или что поведение по-умолчанию будет изменено при апдейте).
Если уж на то пошло, при апгрейде пакета стартовый скрипт тоже может быть переписан пакетным менеджером во многих дистрах. Это отдельное поле для грабель. В апстарте с этим вышел небольшой факапчик, кстати. Потому как указать порядок старта своего сервиса без трогания job-файла чужого сервиса - опа. А тот файл фиг бы его знает как обрабатывает пакетный менеджер при апгрейде, возможны варинаты. А вот Поттеринг о таких вещах подумал, у него вписаться "before" или "after" можно и без колупания чужого unit'а. Сугубо своим новым файлом.
> Еще нет, но с каждой версией это все больше похоже на слова
> Столмана - "у нас, в проекте GNU, было все, кроме ядра".Ну так как-то так оно и было. И хорошо что Линусу не пришлось самому кодить весь юзермод. Это надолго бы заклинило разработку линуха. По этой же причине я не буду сам кодить эрзац-супервизор процессов при наличии готового...
> называться системным менеджером.
Как сказать? Я вот не очень хочу объяснять дубоватому монтажнику как настроить сеть. Особенно в его винде. Поэтому dhcp тоже может пригодиться. А если он не требуется - ну не знаю, у меня network-manager на десктопе живет и сетевые фичи системды ему не мешают. Потому что отключены.
> подходит, так как предполагает управление стандартными блоками системы, а не их
> замещением и интеграцией в себя.А никаких стандартных блоков не образовалось. У каждого дистра были малосовместимые наборы инит-скриптов и костыли и подпорки по месту.
> А еще в emacs есть текстовый редактор ;)
А в системд есть система инициализации :).
> Куда же без них.
Ну вон мсдос обходился и без них. Сама по себе логика сисколов сводится к запрос-ответ, треды не есть нечто абсолютно необходимое в этой парадигме. То что так будет сильно сложнее разрабатывать систему и работать куда паршивее - другой вопрос :)
> Поддержка монтирования сетевых ФС должна быть на уровне ядра.
А она у кого-то что-то занимала, что должна? Линух работает на куче железяк где сети вообще нет.
> Не знал. Ссылка есть?
Да была парочка экспонатов работающих в ядре. В майнлайне их разумеется нет.
> Без средств отладки не обойтись.
Только (вашими же словами вам) они нужны не всем. Применим вашу же противосистемдшную логику? Обойдтесь без дебагера. Сами накрайняк допишете. А сильно вам хочется все бросить и пойти писать дебагер и профайлер, вместо того чтобы дебажить и профаилить? :).
> Проблемы дистра, можно выбрать более подходящий дистрибутив (или вариант ядра в нем)
> либо собрать самому.Ну так системд тоже можно собрать самому и неслабо обрубить. Особо утонченные ценители его даже в openwrt втрамбовать ухитрились, на гитхабе такой эксперимент болтается :)
> Ну видео драйвера тоже работают с железом,
Мне вообще нравится как сейчас сделано. Как бы и не совсем mandatory, но как бы если графика есть - настойчиво рекомендуют DRM/KMS использовать, кроме исключительных случаев.
> да и консоль 80x25 меня лично мало радует.
На моем мониторе 80х25 вообще выглядит отвратительно. Мой монитор - массив 2560х1400 пикселей. Кто не готов с этим столкнуться - деинсталл.
> Притормаживает, но не всегда это критично, постоянно использую - хорошее решение для
> многих проблем.А я этим решением почти не пользуюсь. ФС у меня ядерные. Как насчет применения вашей же логики? :)
> 1. невозможность использовать отдельные компоненты в других системах инициализации
С другой стороны, разные системы инициализации и дистры не заморачивались какой либо совместимостью. Стандарных кубиков не сложилось. Каждый пхал по месту местечковый glue code. Ну вот поттеринг и сбразнул дустом это безобразие. Не скажу что мне их жалко.
С другой стороны, в системд работают другие логгеры. Или даже их отсутствие. И sysv скрипты. Которые к тому же рулятся systemctl (приветы апстарту:P).
> 2. невозможно использовать в минималистичных (без демонов, d-bus, udev) системах.Это имхо актуально разве что для совсем мелочи, типа openwrt. А так нынче даже у модуля с половинку кредитной карты размером ресурсов хватит на два десятка udev'ов и системд.
> можно было и обойтись.
Ну вот без ядерных тредов можно обойтись. И без fuse.
> с sysfs.
А sysfs, на минуточку, тоже опциональный компонент в ядре. И его можно оборвать. У ядра линя на самом деле много чего обрубается :). Как впрочем и у системд...
> Не соглашусь - если бы его разбить на отдельные проекты, то их
> наработки проще бы было внедрять (при необходимости) в другие системы инициализации.Не уверен что это кому-то так уж надо. Было бы надо - имхо отфоркались бы и показали как это делать. А так - большинство компонентов системды таки опциональные. И если хочется, их можно оторвать. На свой зад. Ну так и sysfs в ядре тоже очень на свой зад будет обрывать. И уж тем паче procfs (да, его тоже можно, если СИЛЬНО захотеть).
> решения не должны страдать из-за внедрения новых. Сейчас, например, внедряют nftables,
> но iptables продолжает полноценно работать.Ну так sysv скрипты - работают на системах с systemd, если это надо. И даже удобнее рулятся - все через systemctl. Никто в здравом уме не вынесет это сразу и резко. Будет постепенный phase out.
Спасибо тебе, добрый Аноним, за этот экскурс. Я просто прозрел. Без ироний.
> Спасибо тебе, добрый Аноним, за этот экскурс. Я просто прозрел. Без ироний.Я просто не сторонник предвзятого отношения к софту. Системд - обычная программа. Со своими достоинствами и недостатками, а не исчадие ада, как тут некоторые зилоты пытаются показать. А лучший способ посмотреть нравится ли инструмент - попробовать им попользоваться для решения каких-нибудь задач. Systemd - не стодолларовая купюра, чтобы нравиться вообще всем. Но мне вот нравится. И я могу аргументировать это, как видим. И я не имею ничего против иных точек зрения. Покуда не начинается откровенное вранье или попытки перепихать свои проблемы и предпочтения на других, которые на это как-то не подписывались (да и заставить програмера программить так как хочется мне, а не ему - технически нерализуемая задача, для начала: програмер всегда может вынуть фак из кармана и программить так как он считает нужным).
>И я могу аргументировать это, как видим.Видим, видим! :-D
>> она впала в ступор (то есть это либо аппаратный сбой, либо
>> сбой на драйверов). Причем тут пользовательские процессы?
> Наверное, при том что более высокоуровневая логика поведения железки - формируется этими
> процесами. И если девайс перестанет выполнять свои задачи и потребует к
> себе внимания человека, это опаньки. Даже если ядро и живое, радости
> то с этого?Перезапуск одного повисшего процесса не должен происходить перезапуском всей системы притом через ресет,
>> умеющий использовать особенности различных систем инициализации (с возможностью их
>> отключения на стадии компиляции).
> Ну и с практической точки зрения - вот вы побежите в
> вашей программе запиливать поддержку Menuet OS?Я сам - нет, мне это не нужно. Но если кто пришлет нормальный патч и поддержка будет опцией - почему нет?
> Переписав все на асме, потому
> что у них так принято. Ну и остальные - так же.Зачем? Это Поттеринг любит все заново написать.
>> Возможно, но нужно это далеко не всегда.
> Зато плохо, когда это нужно а этого нет. Самому писать логику супервизора
> процессов мне как-то не улыбается.Речь не о том, что бы писать все самому. А о том что бы иметь много простых решений для каждой задачи. И использовать их по необходимости (типа unix way). А не одно навороченное переусложненное.
>> Мне лично проще отладить скрипт 15-20 строк,
> А мне вот совсем не проще, когда такой шитец не стартует "почему-то".
> А во всех логах - просто ноль. Системд в этом плане
> втыкает с отрывом. Он и код возврата запишет, и вывод программы
> покажет.А sms он пришлет? А пришлет только после третьей неудачно попытки рестарта?
> И даже в /dev/kmsg залоггит, если например ничего другого не
> доступно в энной ситуации. А из скрипта в kmsg самому логгить
> - грабледром, скажу я вам. А если например ФС readonly, а
> экрана принципиально нет - куда еще логгить?tmpfs/devtmpfs - я так на андройде делаю для раннего дебага.
> А никаких стандартных блоков не образовалось. У каждого дистра были малосовместимые наборы
> инит-скриптов и костыли и подпорки по месту.В моем понимании стандартные блоки это драйвера/ФС/сервисы. А инит система - связующее звено для этих блоков.
>> Поддержка монтирования сетевых ФС должна быть на уровне ядра.
> А она у кого-то что-то занимала, что должна? Линух работает на куче
> железяк где сети вообще нет.И? Ненужно - не используй. А с systemd такое не пройдет: не нужен d-bus/udev все равно используй.
>> Притормаживает, но не всегда это критично, постоянно использую - хорошее решение для
>> многих проблем.
> А я этим решением почти не пользуюсь. ФС у меня ядерные. Как
> насчет применения вашей же логики? :)О какой логике речь? Если решение удачное для определенных задач, то почему нет? Вот если бы fuse была обязательным элементом системы. Xorg ее требовал или init система и требование это было слабо обоснованно - то да, я бы возмущался, даже не смотря на то, что я ее (fuse) использую для других (реально обоснованных) ситуаций.
>> 1. невозможность использовать отдельные компоненты в других системах инициализации
> С другой стороны, разные системы инициализации и дистры не заморачивались какой либо
> совместимостью. Стандарных кубиков не сложилось. Каждый пхал по месту местечковый glue
> code. Ну вот поттеринг и сбразнул дустом это безобразие. Не скажу
> что мне их жалко.Ну да, следующий шаг Поттеринга - DE/WM, напишет свой, единственно правильный, а все остальные предаст анафеме, а то нет единообразия на десктопе. При это приложения написанные для его DE будут требовать systemd/PA/его DE.
> С другой стороны, в системд работают другие логгеры.
Но не наоборот. Вам не кажется это несколько настораживающим?
>> 2. невозможно использовать в минималистичных (без демонов, d-bus, udev) системах.
> Это имхо актуально разве что для совсем мелочи, типа openwrt. А так
> нынче даже у модуля с половинку кредитной карты размером ресурсов хватит
> на два десятка udev'ов и системд.А зачем из держать если в них нет реальной необходимости? Можно и винду в виртуалке постоянно держать - ресурсов ПК хватит, но зачем если ты ей не пользуешься?
>> можно было и обойтись.
> Ну вот без ядерных тредов можно обойтись. И без fuse.Без udev/d-bus система работает бысрее и не теряет функциональность - старый ноут (7-8) лет за 9 секунд грузится и жрет около 20mb. Лучше память под кэш отдать, чем под тупо болтающиеся демоны.
>> Не соглашусь - если бы его разбить на отдельные проекты, то их
>> наработки проще бы было внедрять (при необходимости) в другие системы инициализации.
> Не уверен что это кому-то так уж надо. Было бы надо -
> имхо отфоркались бы и показали как это делать.Уже что-то было про logind или что там гном тянет.
> А так -
> большинство компонентов системды таки опциональные. И если хочется, их можно оторвать.То, что их можно отключить != что их можно запустить отдельно без systemd.
> Перезапуск одного повисшего процесса не должен происходить перезапуском всей системыА вот это - зависит от. С чего это вы за всех решили что так - нельзя? Вон у фирмы Нокия, например, у продакшн версий смартов N9 и N9x0 - отвал критичного сервиса ведет к ребуту девайса (разработчики - могут сие отключить). Поэтому если пока телефон лежал в кармане, а что-то пошло не так, оно через минуту будет по крайней мере снова в состоянии принимать звонки и смс. И вы по крайней мере не останетесь в результате без критичной для многих функции "прием звонков" на полдня, сами того не ведая. Нокия называет это MCE - "mission control entity". Да, мобильные девайсы - часто делают похожими на автопилотные, т.к. 95% юзерей - [...] не обладают компетенцией рекавери из системных проблем. Это - почти автопилот. И по состоянию на сейчас - можно объем кода такой штуки скостить в разы, перепихнув многое на systemd.
> притом через ресет,
В системд настраивается что делать. Можно рестарт сервиса (и даже запуск добавочного юнита по поводу "сервис сдох"). Можно рестарт системы. Выбираемо какой именно ребут сделать. Можно совсем корректный, но более склонный к затыку при системных сбоях и проблемах софта (что плохо для автопилотных режимов). Можно форсированный, когда программы не могут заткнуть shutdown sequence, но могут и не сохранить данные. А можно и суперэкстренный - в духе alt-sysrq-b. Где ребут моментальный и обламываться особо нечему. Системы и требования бывают разные. ЧСХ, Поттеринг почему-то в курсе этого факта. В отличие от.
> Я сам - нет, мне это не нужно. Но если кто пришлет
> нормальный патч и поддержка будет опцией - почему нет?Если вам свалится в ваш проект ассемблерная простыня на 100 килобайтов, в которой вы ни в зуб ногой - врядли вы ее станете сами саппортить, just in case. А половина програмеров решит что это тянет на совсем отдельный проект. Не всем же пхать в свои репы любой мусор, как апачевский могильник. Это засоряет код и/или репы.
> Зачем?
В менуэт оси все пишется на асме. Идея фикс у них такая.
> Это Поттеринг любит все заново написать.
ИЧСХ, он нередко умудряется написать лучше, чем то что было до этого. Кроме идеи есть реализация. Ваше while true - типа, "супервизор процесса". Как идея. Но - EPIC FAIL как реализация! Потому что там ни проверки живости процесса, ни лимитирования рестартов, ни таймаутов, ни проверок результатов. Это новое поле для новых грабель, а не решение административной проблемы. Ваш вел из ржавых водопроводных труб - плохо катит. У него слетает цепь. И тормоза на спуске отказывают.
> Речь не о том, что бы писать все самому. А о том
> что бы иметь много простых решений для каждой задачи.Все хорошо в меру. Вот сисколы управления процессами например - то еще лоскутное одеяло. При том привилегированное и чувствительное к порядку вызова.
С административной точки зрения, иметь дело с 20 простых, но совсем разных утилит от разных людей - утомительно. А из-за природы явления - граблебагоопасно и требует от админа глубокого знания устройства системы и работы всех 20 утилит. Прописать 20 параметров в единообразном виде в 1 конфиг - проще. И меньше места для лажи. А фанаты sysv обычно просто кладут на половину подобных вещей. Не обрабатывая ошибки и сбои и делая много фривольных допущений. А когда все нагибается и даже по ssh зайти не получается - ну да, так ваши и должны работать, наверное. Потому что геморно наруливать вызов 20 разных утилит. Особенно с анализом всех мыслимых ошибок в этом процессе. Вот только мне не нравится как все это потом работает.
> И использовать их по необходимости (типа unix way). А не одно навороченное переусложненное.
Тут приводили пример к чему это приводит. Когда чтобы достать 10 файлов из бэкапа - надо распаковать половину архива на 100 гигов. Потому что tar юниксвейно запайпили в gz. И все бы ничего, только сделать seek на середину и распаковать 10 файлов стало нельзя. И даже оглавление посмотреть быстро - опаньки.
Мне в этом плане нравится подход Торвальдса: когда теория и практика сталкиваются - теория идет курить бамбук. Вот все эти ваши рассказы про вэйность и идут куда подальше в ряде ситуаций. В смысле, я не против юниксвея. При условии что так - лучше работает. Есть класс задач, где, действительно, так - лучше. Но - не серебряная пуля. Тем более что системд с точки зрения администрирования в этом плане не так уж плох. Вывод его утилит можно пайпить в другие, etc. Даже вывод journalctl можно загрепать, не парясь бинарностью лога. Хоть это и неэффективно по ресурсам, в индексированном журнале можно и менее безбашенно поиск делать, не читая вообще ВСЁ.
> А sms он пришлет? А пришлет только после третьей неудачно попытки рестарта?
Почему бы и нет? Предположительно, это может быть как-то так: настроить RestartLimit сервису, а в OnFailure сделать вызов one-shot юнита, отправляющего смс. И я бы в этом всем больше всего боялся, имхо, заскоков сотового модема и сотовой сети: сложные штуки с многометровой фирмварью и мегапротоколом. Багов там - выше крыши. И доставка смс - без особых гарантий. И проверять что смс дошла - сложно.
> tmpfs/devtmpfs - я так на андройде делаю для раннего дебага.
А я вот порой логгирую в kmsg. Работает всегда, не требует от меня никаких действий, смотрится обычным dmesg. А что там в ведроиде... я принципиально не работаю с этим крапом. Или борда поддерживается нормальным линем и более-менее майнлайновым ядром, или я ищу другую борду. Все эти мусорные ведра и вендорские SDK пусть горят в аду.
> В моем понимании стандартные блоки это драйвера/ФС/сервисы.
Не вижу чем системд всему этому мешает. Если очень хочется - его можно обрубить до чуть ли не гольного стартера сервисов. А для полноты ощущений неплохо бы обрубить ядру sysfs и procfs. И всякие там sysv ipc. Опциональная же хрень. Требуется не всем :)
> А инит система - связующее звено для этих блоков.
Ну то-есть вы уже тоже не считаете что инит - только запускалка, в стиле "fire and forget", каковой всегда был init и большинство его скриптов?
> не нyжен d-bus
Насколько я помню, там в configure таки есть --disable-dbus. Правда на мой вкус это очень спорная идея. Я за то чтобы в системе был нормальный IPC и это не было бы чем-то сильно опциональным. Оборвать это? Procfs в ядре себе оборвите, больше лулзов.
> udev все равно используй.
Ему довольно мало альтернатив. Ну то-есть можно нечто типа того что в openwrt, но, честное слово, грабель с оборудованием в openwrt много. А юсб какой-нибудь нынче есть даже в модуле с половину кредитной карты размером. А значит и полный букет проблем с горячим подключением оборудования. Время признать очевидные факты: подобная подсистема нужна на большинстве устройств. Потому что там есть как минимум usb. Ваши же аргументы, а? :)
>> насчет применения вашей же логики? :)
> О какой логике речь?О вашей. Нужно не всем -> оборвать.
> Если решение удачное для определенных задач, то почему нет?
Ну я вот считаю что systemd - "решение удачное для определенных задач" - "почему нет"? :)
> Вот если бы fuse была обязательным элементом системы.
Понятие об обязательном - штука растяжимая. Идите вон отключите procfs в ядре. Делаем ставки - сколько софта отвалится :)
> я ее (fuse) использую для других (реально обоснованных) ситуаций.
Ну вот поэтому я не в настроении вопить что fuse - тормозное bloatware, и его надо срочно везде оборвать. Хоть я частично так и считаю :)
> Ну да, следующий шаг Поттеринга - DE/WM, напишет свой, единственно правильный,
Пусть попробует. Вдруг у него получится нечто годное, симпатичное мне? А роты гестаповцев чтобы заэнфорсить инсталл всеми вокруг у него нет. Да и серверам десктоп не требуется. В шапке это понимают.
> а все остальные предаст анафеме,
А он им что, запретит свои апи использовать, под страхом расстрела DMCA? :)
> это приложения написанные для его DE будут требовать systemd/PA/его DE.
А вот это уже дело программистов как писать программы. Да, вы знаете, если я не захочу сношаться с вопросом "а какие там сэмплрейты поддерживает та звуковуха, во сколько потоков и какая гадина заняла звуковуху эксклюзивно" - я таки поюзаю PA. А вы можете наздоровье бодаться с всем этим. Если какой-то анти-PA зилот будет готов накодить патч и майнтайнить по жизни - я может его и приму. Если зилот не будет вести себя как удод и будет это майнтайнить. Но это сугубо акт доброй воли и сугубо на мое усмотрение.
> Но не наоборот. Вам не кажется это несколько настораживающим?
Мне кажется что Поттеринг очень явно дал понять что он делает современную систему инициализации, что у него нет цели ублажать вообще всех, что он намерен пользоваться всеми фичами современной системы - Linux. Да, это накладывает некие лимиты на совместимость и пререквизиты. Но такие лимиты есть в софте везде. А иногда кто-то должен прийти и переопределить как можно делать те или иные вещи. Возможно привнеся новые апи, которые потом будут использовать многие. Возможно даже в разных системах. Чем Поттеринг такой особенный что ему так должно быть нельзя - я не понимаю. С чего бы он должен быть гражданином второго сорта? И эти апи не запрещается реализовывать другим.
Кстати если уж мы о API, библа sdbus от поцтера - как-то лучше чем другие варианты. С точки зрения програминга работы с d-bus на си.
> А зачем из держать если в них нет реальной необходимости?
Ну так не держите. И системд можете не держать. А завтра какой-нибудь умник procfs у себя в ядре отпилит. Мне что, учитывать все причуды всех чудаков на свете? А учитывалка не сломается? Максимум на что такие могут уповать - корректный ФАТАЛЬНЫЙ завал программы с более-менее внятным текстом ошибки.
> если ты ей не пользуешься?
Незачем. Но судя по KVM в ядре - идея запускать виртуалки народу пришлась вполне по вкусу. И мысль оборвать из ядра KVM и прочие namespaces - многие, мягко говоря не поймут. И да, я считаю что системный менеджер должен уметь всем этим рулить. Ну там отпиливать процессы по контейнерам, стартовать виртуалки по тем же критериям как и просто сервисы, etc.
> Без udev/d-bus система работает бысрее
Хорошая опечатка. А так, знаете, udev и d-bus как-то совсем не светятся в top как такие из себя resource hogs. Даже на довольно старой и довольно медленной армовской платке.
> (7-8) лет за 9 секунд грузится и жрет около 20mb.
Правда радость от этого быстро улетучится после запуска обычного браузера. Который один скушает на порядок больше. И вы таки или добьете RAM, или будете слушать хрустение свопом, или будете обуты на современный веб, со всеми вытекающими следствиями.
> Лучше память под кэш отдать, чем под тупо болтающиеся демоны.
Это вон те пару мегов под udev? Имеет смысл только в совсем микроэмбедовке с openwrt. В случае же ноута - любой браузер мигом съест на 2 порядка больше и попросит добавки, аннулировав результат этих потуг. А в типовом дистре будет результативнее вышибить значок на питоне из трэя - сразу +30М RSS, без очевидных потерь, одним выстрелом. В общем какое-то очень нишевое развлечение. Не думаю что Поттеринг обязан учитывать всех извращенцев на планете, занимающихся чем-то странным. С такими приоритетами в пору на openwrt в качестве дистра переходить. Там еще и coreutils заменят на busybox. Если уж RAM превыше всего, тогда ps и top - урезанные сойдут, наверное. И шелл попроще - busybox со ВСЕМИ утилитами весит меньше одного только bash-а.
> Уже что-то было про logind или что там гном тянет.
Если вы давитесь жабой за 2 мегабайта - гном по любому не ваше DE. Они давно не ориентируются на то чтобы втиснуться в 20М RAM.
> То, что их можно отключить != что их можно запустить отдельно без systemd.
Можно. Если вывесить эквивалентное апи. А то что его придется написать - так никто не обещал что будет легко.
>> Перезапуск одного повисшего процесса не должен происходить перезапуском всей системы
> А вот это - зависит от. С чего это вы за всех
> решили что так - нельзя? Вон у фирмы Нокия, например, у
> продакшн версий смартов N9 и N9x0 - отвал критичного сервиса ведет
> к ребуту девайса (разработчики - могут сие отключить).Почему нельзя просто перезапустить сервис, ведь это гораздо быстрее?
>> Я сам - нет, мне это не нужно. Но если кто пришлет
>> нормальный патч и поддержка будет опцией - почему нет?
> Если вам свалится в ваш проект ассемблерная простыня на 100 килобайтов, в
> которой вы ни в зуб ногой - врядли вы ее станете
> сами саппортить, just in case. А половина програмеров решит что это
> тянет на совсем отдельный проект. Не всем же пхать в свои
> репы любой мусор, как апачевский могильник. Это засоряет код и/или репы.Естественно, словосочетание "нормальный патч" подразумевает, что он будет соответствовать общему подходу проекта, включая форматирование кода. Это обычные требования практически всех открытых проектов.
> В менуэт оси все пишется на асме. Идея фикс у них такая.
Так у себя пускай на нем и пишут.
>> Речь не о том, что бы писать все самому. А о том
>> что бы иметь много простых решений для каждой задачи.
> Все хорошо в меру. Вот сисколы управления процессами например - то еще
> лоскутное одеяло. При том привилегированное и чувствительное к порядку вызова.
> С административной точки зрения, иметь дело с 20 простых, но совсем разных
> утилит от разных людей - утомительно.Перечислите все 20. А то кроме iptables и стандартных команд типа mount ничего в голову не приходит.
> А из-за природы явления -
> граблебагоопасно и требует от админа глубокого знания устройства системы и работы
> всех 20 утилит. Прописать 20 параметров в единообразном виде в 1
> конфиг - проще. И меньше места для лажи. А фанаты sysv
> обычно просто кладут на половину подобных вещей. Не обрабатывая ошибки и
> сбои и делая много фривольных допущений. А когда все нагибается и
> даже по ssh зайти не получается - ну да, так ваши
> и должны работать, наверное. Потому что геморно наруливать вызов 20 разных
> утилит. Особенно с анализом всех мыслимых ошибок в этом процессе. Вот
> только мне не нравится как все это потом работает.А по факту, практически все ограничивается стандартными командами и их поведение более предсказуемо.
>> И использовать их по необходимости (типа unix way). А не одно навороченное переусложненное.
> Тут приводили пример к чему это приводит. Когда чтобы достать 10 файлов
> из бэкапа - надо распаковать половину архива на 100 гигов. Потому
> что tar юниксвейно запайпили в gz.unix way запрещает взять более подходящий архиватор, если изначально задача в извлечении отдельных файлов?
>> А инит система - связующее звено для этих блоков.
> Ну то-есть вы уже тоже не считаете что инит - только запускалка,
> в стиле "fire and forget", каковой всегда был init и большинство
> его скриптов?Запускал + перезапускалка сервисов. Остальное - задача сервисов и приложений.
>> не нyжен d-bus
> Насколько я помню, там в configure таки есть --disable-dbus. Правда на мой
> вкус это очень спорная идея. Я за то чтобы в системе
> был нормальный IPC и это не было бы чем-то сильно опциональным.
> Оборвать это? Procfs в ядре себе оборвите, больше лулзов.Зачем? Procfs, sysfs и devtmpfs (написанная кстати Кеем Сиверсом) - отличные вещи, которые я постоянно использую. Да и все ядро жрет памяти примерно столько же, как udev+dbus.
>> udev все равно используй.
> Ему довольно мало альтернатив.Хватает. Можете погуглить. Я лично использую mdev - ничего в памяти не висит, гибкий простой, хорошо поддается дебагу - даже не знаю чего еще хотеть.
> Ну то-есть можно нечто типа того что в
> openwrt, но, честное слово, грабель с оборудованием в openwrt много.Это проблемы дистрибутива (его особенностей или кривых рук).
> А > юсб какой-нибудь нынче есть даже в модуле с половину кредитной карты
> размером. А значит и полный букет проблем с горячим подключением оборудования.
> Время признать очевидные факты: подобная подсистема нужна на большинстве устройств. Потому
> что там есть как минимум usb. Ваши же аргументы, а? :)Не вы меня за человека не считаете? Естественно хотплаг у меня работает и вроде я об этом уже вам рассказывал в предыдущих дискуссиях. Притом правила на каждый девайс составлять одно удовольствие - я себе монтирование флешек сделал с предварительной проверкой fsck (патченный для полного автоматизма). Для 3g модема - настройка и авто запуск pdnsd + polipo. И другие подобные штуки.
>>> насчет применения вашей же логики? :)
>> О какой логике речь?
> О вашей. Нужно не всем -> оборвать.Не оборвать, а сделать опцией!
>> Вот если бы fuse была обязательным элементом системы.
> Понятие об обязательном - штука растяжимая.Простое, если не растягивать ;) Если поставленные задачи выполняются без чего либо, значит оно не нужно.
>> это приложения написанные для его DE будут требовать systemd/PA/его DE.
> А вот это уже дело программистов как писать программы. Да, вы знаете,
> если я не захочу сношаться с вопросом "а какие там сэмплрейты
> поддерживает та звуковуха, во сколько потоков и какая гадина заняла звуковуху
> эксклюзивно" - я таки поюзаю PA.Вот в этом и проблема. Alsa для всех проблемных карты использует dmix и конвертацию частот по-умолчанию. А мало разбирающиеся люди потом клепают PA only приложения :(
А по факту почти всем приложениям приходится поддерживать не только alsa и jack, но еще и pa и oss.>> А зачем из держать если в них нет реальной необходимости?
> Ну так не держите. И системд можете не держать. А завтра какой-нибудь
> умник procfs у себя в ядре отпилит.
> Мне что, учитывать все
> причуды всех чудаков на свете?Нет просто избегать жесткой привязки там, где без нее можно обойтись. Это нормальная практика и вся низкоуровневая часть ее придерживается. Пример с mesa уже приводил.
>> если ты ей не пользуешься?
> Незачем. Но судя по KVM в ядре - идея запускать виртуалки народу
> пришлась вполне по вкусу.Естественно я не против KVM и были случаи когда она меня выручала. Речь только о том, что в системе должно быть запущено только то, что необходимо для решения текущих задач.
> А так, знаете, udev и d-bus как-то совсем не светятся
> в top как такие из себя resource hogs. Даже на довольно
> старой и довольно медленной армовской платке.Ну и смысл тратить на них память?
>> (7-8) лет за 9 секунд грузится и жрет около 20mb.
> Правда радость от этого быстро улетучится после запуска обычного браузера. Который один
> скушает на порядок больше.Да, но ее все же будет больше, а вероятность свопа меньше.
>> Лучше память под кэш отдать, чем под тупо болтающиеся демоны.
> Это вон те пару мегов под udev? Имеет смысл только в совсем
> микроэмбедовке с openwrt. В случае же ноута - любой браузер мигом
> съест на 2 порядка больше и попросит добавки, аннулировав результат этих
> потуг. А в типовом дистре будет результативнее вышибить значок на питоне
> из трэя - сразу +30М RSS, без очевидных потерь, одним выстрелом.Естественно, оптимизация должна быть комплексной и избавление от d-bus/udev это только ее малая часть.
А по факту - браузер palemoon (дополнительно зачищен при сборке). Ест в среднем 150-300MB + 20MB система. Естественно система 32 бита. На ноуте 2GB памяти. Ее хватает чтобы не закрывая браузер работать со звуком или графикой, не залазить при этом в своп. Софт весь свежий.
> в пору на openwrt в качестве дистра переходить. Там еще и
> coreutils заменят на busybox.Уже, лет пять - и как вы говорите: ЧСХ без проблем работают все обычные десктоп приложения (кодинг/графика 2d+3d/работа со звуком) и даже LO дебиановской сборки.
> Если уж RAM превыше всего, тогда ps
> и top - урезанные сойдут, наверное.Ну зачем так сурово? Busybox с конфигом под десктоп (нормальный top/ps/etc) - 387KB, нет смысла его сильнее кромсать.
> И шелл попроще - busybox
> со ВСЕМИ утилитами весит меньше одного только bash-а.Да, но некоторые пакеты при сборке страдают башизмами. Да и виртуальная консоль в mc нормально без баша не работает. А так да - инит скрипты на простом шеле.
> Почему нельзя просто перезапустить сервис, ведь это гораздо быстрее?В общем случае, ребут - предсказуемее. Такие системы создают в виде когда они при включении безусловно выходят на режим, а риск развала системы при ребутах, даже внеплановых и power loss - минимизируется. Fsck на телефоне? Не катит. И мало ли где еще внутренний state развалился. Знаете, погано если телефон пропустит 5 важных звонков, будучи полдня в ауте (и у менее сообразительных вендоров такое бывает).
> Это обычные требования практически всех открытых проектов.
Тем не менее, это дополнительная сущность.
> Так у себя пускай на нем и пишут.
Так они это и делают. А если к вам припрется юзерь этой штуки и с нахрапом потребует переписать вашу прогу вот так - ваш оптимизм это делать предсказуем. Ну вот и остальные програмеры и прочие майнтайнеры при виде "вы мне тут все должны" тоже могут фак из кармана вынуть.
> ничего в голову не приходит.
Слабая фантазия!.
- Что насчет таймаутов? Старт, стоп, время работы (актуально для oneshot юнитов). Это даже не команды. Это целые блоки кода и настройки.
- А что насчет приоритетов?
- Выставление юзера, группы.
- Смена шедулеров?
- Лимиты ресурсов?
- Capabilities минимально нужные? В системд - легко!
- А лишние сисколы seccomp-ом рубануть? См. выше.
- Namespaces aka контейнеры? Создать или присоседиться. А то и ОС туда задеплоить.
- Как насчет вачдогования живости процесса и прочих действий "а-ля нокиевский MCE"?Для половина этих хотелок - целые блоки кода, а не команды. С обпрыгиванием кучи дурных грабель. Про которые с наскока можно и забыть со своим while true, между прочим. А потом, когда оно отвалится в боевой системе... ну в общем, я на такое насмотрелся. А фантомас в очках на аэроплане для скриптеров - все это сделать и при этом еще и залогить весь вывод и обработать все ошибки всех программ. А что, системд именно так и делает.
> А по факту, практически все ограничивается стандартными командами и их поведение более предсказуемо.
Я не знаю "стандартной команды" для логики вачдогования процессов. И не хочу выписывать целый блок кода для замера таймаута старта и убиения сервиса. В системд это 1-2 директивами делается. А за несколько лет - там обпрыгают (и уже многое обпрыгали) развеселые грабли вида "пришел ntp и крутанул часы в этот момент". А вам в вашем скриптодобре подобные грабли запросто укатают в лоб. Этак 29 февраля, високосного года, после дождичка, в четверг. Без диагностики "а какого оно так". И удачи поймать такой баг.
> unix way запрещает взять более подходящий архиватор, если изначально
> задача в извлечении отдельных файлов?Общая логика процесса плохо накладывается на пайпинг: надо чтобы архивер и компрессор были одной сущностью, а не двумя и кооперировали более плотно чем это комфортно и логично делать через пайп. Компрессор должен быть file-aware и знать где оглавление. И форсировано сбрасывать состояния на характерных границах, удобных архиватору, чтобы позволить декодирование с именно этого места. А "слепой" компрессор, жмущий вход на выход - не дружит с идеей "достать файл из середины". А архиверу неплохо бы знать насколько сжался "вон тот файл". Чтобы к "вот этому файлу" информированно отмотать за разумное время. Не декомпресся и даже не читая весь 100-гиговый файл.
Делать квази-RPC к компрессору, с директивами сброса состояния проталкиваемыми через пайп - наверное можно, но - изврат. Сложно и криво. И уже не юниксвэй, т.к. произвольный компрессор уже не прокатит.
> Запускал + перезапускалка сервисов.
То как оно это делает - из разряда "и даром не возьму".
> Остальное - задача сервисов и приложений.
Ну конечно, все прогеры в восторге требовать старт под рутом, со всеми CAPSами и далее лично кодить кучу системной логики, типа смены шедулеров, приоритетов, юзерей и прочая. Они мечтают возиться с отсоединением std*, париться с уталкиванием себя в новый namespace, и уж конечно какой же програмер откажется написать вачдог-супервизор процесса. А это - вовсе и не сарказм.
> которые я постоянно использую.
Ну как, они опциональны. Без них можно обойтись. Если форсить логику зилота по экономии ресурсов - надо их срубить. Так что не надо их использовать.
> Да и все ядро жрет памяти примерно столько же, как udev+dbus.
А браузер может скушать в 100 раз больше. И?
> Хватает. Можете погуглить.
А мне это зачем? Я больше всех хочу попрыгать по нестандартным граблям, убив много сил ради маргинального выигрыша?
> висит, гибкий простой, хорошо поддается дебагу - даже не знаю чего еще хотеть.
А мне 2 метра памяти на udev обычно жить не мешают. Кроме урезанных железок, где уместен openwrt. Но там обычно большой напряг с хорошей поддержкой оборудования и плагнплеем как таковым. Т.к. для начала - в девайсе нет места на все драйверы, скажем, usb-девайсов.
> Это проблемы дистрибутива (его особенностей или кривых рук).
Это скорее общее сочетание свойств дистра с железками на которых есть смысл его применять. Они сами, прямым текстом пишут что на девайсах с >=128Мб памяти и гигазом NAND есть смысл смотреть на более полноценные дистры, типа дебиана.
> Не вы меня за человека не считаете? Естественно хотплаг у меня работает
С учетом ваших странноватых предпочтений - я это могу предполагать только после явного уточнения.
> и вроде я об этом уже вам рассказывал в предыдущих дискуссиях.Извините, значит я это прошляпил.
> монтирование флешек сделал с предварительной проверкой fsck
Во, логика мамонта: вместо устранения root cause - сделать костыль. При том если флеха большая, а файл нужен быстро - ну да, именно fsck в этот момент и не хватало.
> (патченный для полного автоматизма).
ИМХО это довольно спорная идея. Не говоря о том что человеческое решение было бы использовать ФС которая не разваливается при выдергивании флехи наобум до состояния когда надо полный fsck. Вы же выключаете какой-нить домашний роутер отключением питания и не паритесь что встроенная ФС слетит. И никаких fsck там нет.
> И другие подобные штуки.
Все это же можно и на udev сделать. Я себе сделал рандомизацию мак-адресов на беспроводных интерфесах, например. При появлении и-фейса. И переименования ифейсов напрочь переиначил.
> Не оборвать, а сделать опцией!
Если насчет udev я еще со скрипом могу согласиться, хоть выигрыш от этого мне и не очевиден, то вот нормальную системную шину с точки зрения программирования я бы хотел видеть "условно-mandatory". Ну то-есть если и обрываемой то только в совсем low res эмбедовке а-ля openwrt. Иначе програмить это потом хреново будет.
> Простое, если не растягивать ;) Если поставленные задачи выполняются без чего либо,
Выполнять задачи можно по разному. Говорю же - можно и ядерные треды оборвать при сильном желании. Выполнять все сисколы синхронно, по мере поступления. Работать же будет!
А такие параметры как качество работы (в утрированном примере с сисколами - латенси, многопоточность, etc) у вас в метриках совсем не фигурирует. Вот sysv init - примерно так же, как оборвать ядерные треды и сделать пещерную, синхронную, 1-поточную реализацию сисколов - "можно обойтись" же. Ну, обходитесь.
> А мало разбирающиеся люди потом клепают PA only приложения :(
А им даром не упало разбираться в интимных проблемах алсы. Люди хотят проигрывать звук, а не сношаться с интимными особенностями звуковух, алсы, их опциональных довесков или чего там еще. И даже libSDL, абстрагирующая все и вся, от OSS до WinAPI - предпочтет при наличии пульса и алсы задействовать пульс, что как бы намекает что горлопаны с опеннета выдают желаемое за действительное. А на практике с пульсом проблем меньше чем с алсой.
> А по факту почти всем приложениям приходится поддерживать не только alsa и jack, но еще и pa и oss.
При том Jack используют только узкоспециализированные приложения. На OSS почти все забили. А немало программ, натурально PA-only. Для особо упертых зилотов вроде даже какой-то костыль есть для вывешивания алсой пульсовского апи. А для меня, pulse - worksforme, обеспечивает ряд полезных мне фич и никаких проблем мне на моей памяти не создавал. Поэтому потоки помоев в адрес пульса я считаю преувеличенными и иррациональными.
ИМХО, когда некто начинает страдать контрпродуктивными предрассудками и чрезмерной разборчивостью - пусть они и бодаются с костылированием. Так вполне честно.
> Нет просто избегать жесткой привязки там, где без нее можно обойтись.
Я в общем случае как-то совсем не рвусь сконвертировать чужие чудачества и предрассудки в мои сложности. Поэтому если некто уже накодил нужную программу, либу или что там еще - я вполне могу это задействовать, если это упростит мне жизнь. Я в курсе что махать факом все время - не лучшая идея. Но другой стороны, плохо и когда всякие умники с нахрапом садятся на шею и начинают качать права, рассказывая кто и что "должен". Реально будет тот или иной баланс и сильно махать требованиями перед програмерами и майнтайнерами - не получится.
> Это нормальная практика и вся низкоуровневая часть ее придерживается. Пример с mesa
> уже приводил.Случаи бывают разные. Разумеется, специально ломать совместимость - свинство. Но и усложнять себе жизнь без ощуимого выигрыша - мало кто мечтает. А за ВСЕХ расписываться к тому же нескромно и чревато уличением во вранье.
> то, что необходимо для решения текущих задач.
Для general purpose систем множество задач не является четко определенным и избежать некоего оверкилла и оверхеда, являющихся расплатой за универсальность - не получится.
С точки зрения оптимальности, оптимальнее всего испечь ASIC рюхающий "эту задачу". Минимально возможным числом транзисторов, с максимальной скоростью. Но есть нюансы...
> Ну и смысл тратить на них память?
Для меня вопрос ставится иначе: "какой смысл возиться с экономией 2Mb RAM по линии udev'а на большинстве железяк?" Ответ на этот вопрос я знаю только для совсем мелких девайсов на которые ставится openwrt...
> Да, но ее все же будет больше, а вероятность свопа меньше.
В общем случае я считаю что своп должен умереть. Особенно на механические hdd. На дворе 2015 год, RAM нынче емкий и дешевый. И нет никакого смысла эмулировать недостающий RAM тормозным hdd, у которого с random access плохо. В лине, правда, есть парочка интересных вещей. Скажем, ZRAM. А вот своп на механику - плох для latency программ. Это неприемлимо ни для десктопов, ни для эмбедовки, ни для серверов, по большому счету.
> Естественно, оптимизация должна быть комплексной и избавление от d-bus/udev это только
> ее малая часть.ИМХО, настолько ядреный уровень оптимизации имеет смысл лишь в сильно некоторых системах и по сильно некоторым поводам. А окучивать так обычный десктоп - контрпродуктивно.
> А по факту - браузер palemoon (дополнительно зачищен при сборке). Ест в
> среднем 150-300MB + 20MB система.И ваши 2 мега идут лесом, когда невъ... XUL-ятина и явоскриптятина запускается. И скриптокидозники делавшие вон тот сайт - не парились как вам 2 мега сэкономить на их сайте.
> 2GB памяти. Ее хватает чтобы не закрывая браузер работать со звуком или графикой,
Смотря что понимать под "работой с графикой". Вон например DarkTable для хорошей работы хочет побольше ядер проца и побольше памяти под кэши. И на 8-ядернике с 16 гигз он работает сильно резвее чем на 2 ядрах и 2 Гб RAM. К тому же, дисковый кэш на несколько гигов - уменьшает seek механики и протирание ssd. Он и от OpenCL не откажется, охотно выпихнув тяжеленные и параллелящиеся операции на GPU. Это - работа с графикой, 2015 год.
> не залазить при этом в своп.
У меня обычно нет свопа на механических дисках. Я себе не враг.
> Уже, лет пять - и как вы говорите: ЧСХ без проблем работают
А я недооценил вас как маньяка оптимизации.
> Busybox с конфигом под десктоп... - "взаимоисключающие параграфы" :)
> 387KB, нет смысла его сильнее кромсать.Такому размеру роутеры позавидуют. Но что ни говори, а даже в полной сборке утилсы из бизибокса обрубленные, упрощенные и имеют меньше опций. Они, конечно, нужны не всегда. Но если опции нужны, а их нет... упс.
> Да, но некоторые пакеты при сборке страдают башизмами.
И утилиты в бизибоксе урезанные. Большинство сетевых утилсов там очень упрощенные. И если на роутере изучать "а что он вообще делает" каким-нибудь netstat приходится редко, то на десктопе это куда более частое явление и имхо можно позволить себе нормальные утилиты. Я ж не ставлю целью влезть в 32Мб RAM при том что 20 уже съело ядро и прочие бизибоксы :)
> Да и виртуальная консоль в mc нормально без баша не работает.
Вот только один баш весит как 2-3 ваших бизибокса :)
> А так да - инит скрипты на простом шеле.
Да и фиг с ним. Я с удовольствием забуду про это безобразие как страшный сон.
> Дополню. Все хаят systemd, за то, что тянет внутрь себя слишком много
> функциональности. Но совершенно не замечают того, что ядро занимается тем же
> самым.Ядро это делает из технической необходимости, ибо, лишь например, в нём размещаются такие вещи, переключение контекста между которыми крайне нежелательно.
А systemd так делает из-за лени разработчиков делать по-человечески, IMO.
>Дополню. Все хаят systemd, за то, что тянет внутрь себя слишком много функциональности. Но совершенно не замечают того, что ядро занимается тем же самым.Для тебя наверное и
#ifdef
великое и непознаваемое шаманство
> Бедное ядро, столько шлака в него пихают, и всё без толку)Экий батхерт у фрактала то. Ну конечно, намного лучше когда нвидия не может три года к ряду запилить свой эрзац KMS-а, поэтому их драйвер работает откровенно через гопу.
Бабахает у амд-фанбоев из-за их глючного и тормозного драйвера, а баттхёрт почему-то у меня)> их драйвер работает откровенно через гопу
Амдшным высерам бы так работать, лол.
> Бабахает у амд-фанбоев из-за их глючного и тормозного драйвера, а баттхёрт почему-то у меня)А не ты ли ныл про баги нвидии, которые никто не чинит, фанбоище? :) А я вот нарепортил амдшникам багов. Они замочили их ВСЕ. Даже глюкалово в opencl в наиболее донимавших меня кейсах - побустали. Вот это я понимаю - работают люди!
>> их драйвер работает откровенно через гопу
> Амдшным высерам бы так работать, лол.Не, спасибо, так - не надо. Мне ни к чему драйвер, отпадающий при смене ядра. Мне ни к чему драйвер который не может отрисовать KDB. Мне ни к чему драйвер который не может без глюков отрисовать фреймбуферную консоль. И да, я считаю самоличную инсталляцию драйвера, с прописыванием конфига чем-то типа пережитка эпохи DOS. Это тогда было модно запускать setup.exe который пропишет драйвер в config.sys. Или в хучшем случае самому прописывать. А сейчас у меня XXI век на дворе. И я очень хотел бы чтобы допустим дефолтный образ какой-нибудь убунты на моем оборудовании просто запускался бы и не канифолил мне и окружающим мозг. Потому что компьютеры должны помогать работе и решать проблемы, а не создавать новые.
> А не ты ли ныл про баги нвидии, которые никто не чинит, фанбоище? :)Неа. Я вообще не втречаю никаких багов на нвидии. Единственный упрёк в их сторону - шибко текут иксы при использовании суспенда, но у меня теперь комп вообще круглые сутки работает, так что упрёк актуальность потерял.
> А сейчас у меня XXI век на дворе.
У меня тоже. Поэтому я делаю emerge nvidia-drivers и усё) И если мне хочется поиграть - я знаю, что любая игра, которая запускается и работает нативно или через wine, будет работать как положено, а не с 15 fps или с винегретом на экране вместо изображения)
> их сторону - шибко текут иксы при использовании суспенда,А это что? Фича, чтоли? Ну его в пень такие фичи! :)
> меня теперь комп вообще круглые сутки работает,
Зато юзеры ноутов наверное очень рады. Впрочем, ноуты с нвидией обычно быстро вымирают. Нет ноута - нет проблемы! Фирменная политика нвидии.
> так что упрёк актуальность потерял.
Да, давайте строиться под причуды проприерасов. Вот только это... а нафуя мне еще одна винда? Опенсорс тем и хорош что не надо строиться под всяких пи...сов-проприерасов.
> У меня тоже. Поэтому я делаю emerge nvidia-drivers и усё)
...а memleak починить не того. Мне так не нравится. Это как в винде, буквально. А вот наколотить баг в нормальный багтрекер, посмотреть что починили, проверить на своей конфиге что и правда починили - это я понимаю, разговор.
> и работает нативно или через wine, будет работать как положено, а
> не с 15 fps или с винегретом на экране вместо изображения)Ну мы то это запинаем сообща. А вот memleak у нвидии может запросто болтаться годами. Этим проприерасия от опенсорса и отличается.
> а не с 15 fps или с винегретом на экране вместо изображения)Лол, что? У меня на radeonsi через wine или нативные игры steam дают 90+ fps, какие 15fps с винегретом?
> ... а не создавать новые.А ты не обновляйся. Вот ядре исправили багу с TIPC протоколом, ты о нём сейчас
в первый раз полезешь читать на гугол, зато все апдейты уже стоят. :D
Не, я бы понял если бы ты интел сравнивал с нвидиа. Но галимую ати-растию.
Интел работает ок, нивидиа ок, а с ати-амд вечно жопа. Нвидиа уже в 2001 (когда ты пешком под стол шастал) давала нормальное xv, в отличии от ати, которые вообще работали как vesa. Они и под вантузом работают то через пино-коладу.
> Не, я бы понял если бы ты интел сравнивал с нвидиа. Но
> галимую ати-растию.
> Интел работает ок, нивидиа ок, а с ати-амд вечно жопа. Нвидиа уже
> в 2001 (когда ты пешком под стол шастал) давала нормальное xv,
> в отличии от ати, которые вообще работали как vesa. Они и
> под вантузом работают то через пино-коладу.Да бесполезно тут про АМД писать. Тут одни нищеброды с дешёвыми буками на амд за 200$
Они срали и будут срать. И минусить будут.
> Да бесполезно тут про АМД писать. Тут одни нищeброды с дешёвыми буками на амд за 200$Угу, я тут с дешевым R9 270. Потому что он с опенсорсным драйвером довольно прилично пашет, без этой вашей долбаной блоботни. А винда номер два мне не требуется, спасиб :)
> Многочисленные оптимизации и переработки ассемблерного кода для архитектуры x86Только для 32 бит, или 64 бит тоже касается?
В ядре оба считаются за одну архитектуру.
Так F2FS ещё не дошла до стабильной. Вот оно чё...
А что используют всякие там новые ведроиды в качестве ФС на SD карте (у которых она есть конечно)? exFAT?
> Так F2FS ещё не дошла до стабильной. Вот оно чё...
> А что используют всякие там новые ведроиды в качестве ФС на
> SD карте (у которых она есть конечно)? exFAT?я как-то пользовал активно для колекции музыки на флешке. Показалось стабильным. Был только один баг - кирилицкие имена в один прекрасный момент умерли (вроди обновление ядра довело до такого). побагрепортил, пообщался с поддержкой. вернул взад все, но с новым ядром мне оказалось не по дороге. Откатываюсь назад на старое ядро. Оппа! Кирилица опять в оффсайде. После починки старые дрова не рулят. В общем так мой опыт с ф2фс и закончился...)))
Ну так номальный путь - репортнуть баги в новом ядре. Чтобы с ним стало по дороге :)
Как время-то летит.. Совсем недавно было 2.4...
Недавно это когда? 2.4 это 2001 год, если что :-)
в том то всё и дело
Блин! А как же теперь быть с версией ядра 4.1.15, на которой работал Терминатор Т-800 ?
Скайнет сам недостающие патчи напишет и версию бампнет.
> Блин! А как же теперь быть с версией ядра 4.1.15,Ну так надо 4.1 объявить LTS-ом :). Впрочем, скайнет наверное и сам справится.
> на которой работал Терминатор Т-800 ?
Ты имеешь что-то против заппгрейженых вариантов терминатора? :)
как обычно не собирается нвидия...
GPL-incompatible module nvidia.ko uses GPL-only symbol 'flush_workqueue'патчим... нвидиа-такая-нвидиа...
https://forums.geforce.com/default/topic/849487/linux-v4-2-u...-/
Какой жир по ссылке.> ... and people wonder why Linux struggles with adoption. here we have an artificial breakage of a driver that is essential to a good user experience for many users, especially if they want to game or perform any of the activities that people still see windows/osx as being more useful for. this is just a tantrum about nvidia and other companies not open sourcing their drivers.
> news flash: breaking their ability to build to the kernel is not going to make them open source their stuff. it just drains resources that could be spent improving the stability and performance of the drivers into finding kludgy workarounds for the asinine punishment of being banished from using kernel functions. management doesn't care. this just makes life difficult for developers at these companies who probably go to bat for the linux community all the time. all it's going to do is make the official drivers for hardware crappier over time. the state of nouveau is enough to show why we need support from the hardware manufacturers. antagonizing them doesn't help.
> what purpose does exporting any symbol *only* to GPL'd packages serve? it's just an exertion of pedantic, mouthbreathing, fedora-clad neckbeardery. gross.https://forums.geforce.com/default/topic/849487/geforce-driv...
Это ты ати-растию не видал еще
> как обычно не собирается нвидия...Рукожопые юзеры должны страдать!
# uname -a
Linux amd64 4.2.0 #13 SMP PREEMPT Tue Aug 31 03:23:58 MSK 2015 x86_64 GNU/Linux
# dmesg | grep NVI
[ 3.772596] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 346.87 Tue Jul 14 18:29:34 PDT 2015
> Рукожопые юзеры должны страдать!Умение разгребать гуано за нвидией - такой предмет гордости, оказывается. Оказывается, бывают и дворники от айти - убирают г-но за проприетариями.
>> Рукожопые юзеры должны страдать!
> Умение разгребать гуано за нвидией - такой предмет гордости, оказывается.Да, разгребу и буду спать спокойно. АМДшнеги продолжать жить в говне,
а интелята так и будут думать, что у них не эмулятор видеокарты с программным рендерингом. :D
> Да, разгребу и буду спать спокойно.Без нормального багтрекера? С некооперативными разработчиками нвидии? И ядерщиками майнлайна, дружно достающими фак из кармана при виде tainted kernel? Удачи тебе в этом начинании, Павлин.
> АМДшнеги продолжать жить в гoвне,
Да вот знаешь, GL 4.1 в MESA уже запилили. Баги которые я зарепортил - все поудавили. А проблем характерных для проприерастии - отродясь и не имели. Мне такой формат взаимодействия и результаты больше нравится, кекеке.
> а интелята так и будут думать, что у них не эмулятор видеокарты
> с программным рендерингом. :DУ них просто GPU архитектурно отсталый, а не программный рендеринг. Посмотри в каких семействах они opencl начали осиливать. До этого у них чуть ли не деление по типам шейдеров было. А еще у большинства интеграта нет своей локальной памяти. А когда проц и GPU дружно делят тощий (vs GDDR5) бандвиз DDR3 на всю ораву, понятно что получается.
У интела еще есть ириска. Там они доперли GDDR5 таки допаять. Прям на проц. Вот правда стоит оно в результате как самолет, а GPU у интеля таки поганые. Можешь получить аналог чего-то между HD6570 и HD6770. По цене как три HD6770. За бренд надо доплачивать, однако :). На месте AMD я бы прикрутил туда HBM и показал как это надо было делать правильно...
павлин, ты чо там с бодуна чтоль злой?! чукча не читатель- чукча- пейсатель!
ты хоть ник-то смари и ссыль... уж пропатчить то руки есть, я не про то вообще писал!# uname -a
Linux 7-21a-226-o1182 4.2.0 #1 SMP PREEMPT Tue Aug 31 08:13:40 SAMT 2015 x86_64 Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz GenuineIntel GNU/Linux#dmesg | grep 355
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 355.11 Wed Aug 26 16:35:41 PDT 2015
> В libata улучшена поддержка NCQ (Native Command Queuing) TRIM. Для включения и отключения NCQ TRIM представлены параметры ncqtrim и noncqtrimЭто как-нибудь связано с недавней ошибкой в асинхронном TRIM, выявленной на Samsung 850?
> Код выборки по именам файлов переработан для исключения рекурсии, что позволило сократить нагрузку на стек, повысить надёжность работы сложных систем хранения и убрать лимит на глубину вложенных символических ссылок;Никто сходу не знает где можно найти документацию по данной feature?
> Никто сходу не знает где можно найти документацию по данной feature?Документация на багфикс с устранением дурного ограничения? Наверное в git log -p :)
СТОП!!! А как же 4.1.15?
Ветка 4.1 вроде будет longterm, рано отчаиваться.
> СТОП!!! А как же 4.1.15?"Микрософт корпорация всегда работает над тем чтобы вас лучше сделать".
Читаю, комменты и вижу, что не все хорошо и гладко в линукс. А когда читаешь, комменты к статье о других ОС (фря например), то создается впечатление, что в линукс все идеально в впереди планеты всей. Ни в коем случае не повод для холивара. Просто заметка на полях...
> Читаю, комменты и вижу, что не все хорошо и гладко в линукс.Ага, ты понял суть. В остальных просто еще хуже.
Но есть градации. OSX например намного луше вантуза, особенно если с homebrew
> OSX например намного луше вантуза, особенно если с homebrewА какая, собственно, разница - майкрософт будет навязывать правила игры или эппл? Все отличие - в смене одних м...ков на других. Но и те и другие - проприетарные уроды с фощысской EULA, по которой они короли а вы ... ну в общем почитайте EULA, узнаете за кого вас там держат :)
В новом ядре 4.2.1-1 4.2.1-2 на опенсьюзе стал вылетать Bcache поверх mdadm raid5
На ванильном ядре тоже самое...
