Бастьен Ноcера (Bastien Nocera), разработчик Totem, Rhythmbox и gvfs, входящий в управляющий комитет GNOME Foundation, анонсировал (http://www.hadess.net/2015/05/iio-sensor-proxy-10-is-out.html) первый выпуск фреймворка iio-sensor-proxy (https://github.com/hadess/iio-sensor-proxy), предназначенного для упрощения работы с различными аппаратными сенсорами, которыми комплектуются современные ноутбуки и планшеты. В основе iio-sensor-proxy лежит демон, который отслеживает состояние шины IIO (Industrial I/O) и транслирует обращение к сенсорам через шину DBus.
Доступный для приложений высокоуровневый D-Bus API построен по мотивам программных интерфейсов для работы с сенсорами, предоставляемыми платформами Android и iOS. В настоящее время уже поддерживается работа с акселерометром и датчиком освещённости, ожидается поддержка магнитометра, компаса и датчика приближения. Также планируется реализовать возможность обращения к акселерометру в raw-режиме и провести адаптацию SDL, Firefox и WebKit для использования нового фреймворка.
В настоящее время поддержка iio-sensor-proxy уже добавлена в GNOME и будет доступна в ближайшем тестовом выпуске 3.17.2 в форме опции автоматического управления яркостью экрана и возможности адаптации интерфейса к горизонтальной или вертикальной ориентации устройства.<center><a href="http://1.bp.blogspot.com/-wYL0Xq_bA_k/VV9JQVH6q6I/AAAAAAAAAt... src="http://www.opennet.me/opennews/pics_base/0_1432360873.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Из требуемых для работы iio-sensor-proxy зависимостей отмечаются libgudev и systemd. Фреймворк протестирован на устройствах
Lenovo IdeaPad Yoga 13, Microsoft Surface Pro 2, Lenovo Yoga Pro 2, Onda v975w, Dell Venue 8 Pro и Lenovo ThinkPad Twist. Примечательно, что вначале iio-sensor-proxy был создан как заглушка, предоставляющая доступ к сенсорам подсистемы IIO через эмуляцию уже поддерживаемого в GNOME акселерометра планшета WeTab. Но такой подход не оправдал себя, несмотря на обеспечение совместимости с ранее выпущенными версиями GNOME, поэтому iio-sensor-proxy был трансформирован в полноценный фреймворк, предоставляющий DBus API.URL: http://www.hadess.net/2015/05/iio-sensor-proxy-10-is-out.html
Новость: http://www.opennet.me/opennews/art.shtml?num=42287
Унификация интерфейса к датчикам это хорошо, прикрутили бы сразу возможность опроса датчиков температуры через DBus чтобы сразу всё унифицировать.
> температуры через DBus чтобы сразу всё унифицировать....и оборотов вентилятора, и PWM. А что, напишите им фичреквест :)
> systemdКак же без него...
Да хрен с ним. Если бы ещё пару больших компаний уровня IBM и Оракла взяли бы Поттеринга за яйца, то вообще было бы неплохо. А то пока Лёньку тянет один Red Hat и хрен его знает куда он его притянет.
А вот руководи разработкой systemd консорциум из независимых компаний, то глядишь получилась бы офигенная унифицированная прослойка между ядром и прикладным софтом.
Видимо пример Линуса никого ничему не научил. Консорциум создается не на пустом месте, а когда уже есть какая-то идея, начальная реализация и хотя бы один заинтересованный разработчик. Иначе неясно на что, кому, зачем вкладывать деньги.
>а когда уже есть какая-то идея, начальная реализация и хотя бы один заинтересованный разработчикSystemd отлично подходит под этот критерий. Есть и идея (поглощение и унификация всяких околосистемных улилит), начальная реализация (systemd уже работает) целая заинтересованная компания (Red Hat)
Идея сталкивается с вопросом: ну и нафига это надо, если и старое работает отлично.Начальная реализация: не очень-то и работает. Внедряли вот в Debian, обещали загрузку ускорить (да, да, поттеринг настаивает, что это побочный результат), а в итоге что? Загрузка в полтора раза замедлилась по сравнению с sysvinit.
Заинтересованная компания Red Hat: заинтересована в том, чтобы установить вендор-лок на свои разработки. Кому, кроме неё, это надо?
> Идея сталкивается с вопросом: ну и нафига это надо, если и старое
> работает отлично.Понятия о хорошем у всех разные. Ну вот например: https://ssl.opennet.ru/openforum/vsluhforumID3/102685.html#107
Внимание, вопрос: а у ТЕБЯ есть решение на этот случай лучше поттеринга? Гражданин Шигорин в своих антипатиях к Поттерингу уже кажется лопухнулся и скатился в необъективность.
> Внимание, вопрос: а у ТЕБЯ есть решение на этот случай лучше поттеринга?У любого матёрого админа для админа есть решение лучше, чем у человека, который кичится тем, что не админ.
> Гражданин Шигорин в своих антипатиях к Поттерингу уже кажется лопухнулся
> и скатился в необъективность.Можно пример антипатий _и_ необъективности? Вот некоего User294 на антипатиях и необъективности замечал, о чём старался ему же и сказать, пояснив позицию.
> У любого матёрого админа для админа есть решение лучше, чем у человека,
> который кичится тем, что не админ.Какой-то очень спорный тезис, имхо. И вот вы пока, имхо, вместе с другими хейтерами кичитесь контрпродуктивным хейтерством и предвзятым отношением, не допуская и мысли что кому-то, а возможно даже много кому, те или иные подходы окажутся удобны и вполне по вкусу. Пока что я вижу что у матерых админов находится дофига упертости, ЧСВ и нежелания обучаться и просто допускать мысль что возможны различные варианты того что людям нравится. Как бы удачи в таком подходе. Но мне такое отношение к жизни не нравится. Я вот поупражнялся с системд - инструмент пришелся по руке. А еще с udev поупражнялся. Тоже вполне себе понравилась приблуда. Свои задачи они решают вполне нормально. И я в этом вижу хоть какую-то логику. В отличие от хейтеров, которые, видимо, считают что я должен идти на йух с моими сложностями и, наверное, по жизни кодить себе запускалки сам, если хочу пользоваться актуальными фичами моего ядра.
А вот например туеву хучу скриптов на пять страниц в бутовой последовательности ОС, с кучей грабель, никаким логгингом, пофигизмом на ошибки и прочее лично я у себя в системах видеть не хочу. А еще - системные дела делаются через системные вызовы. Которые не больно поделаешь через скрипты. Вот через сишные утилиты - это да. Поцтер не идеален. Наверняка можно лучше. Но остальные вообще забили болт и у них clone() с CLONE_NEWUSER вот так сразу - не позовешь вообще. А всякие рассказы про OVZ и прочее - уже не то.
Вот лично я например вполне в настроении пользоваться контейнерами и VM не только на супер-серверах, но и вполне себе на моем десктопе. С свежим ядром. И желательно по дефолту. Это делает мою жизнь проще в ряде аспектов.
> Можно пример антипатий _и_ необъективности? Вот некоего User294 на антипатиях и
> необъективности замечал, о чём старался ему же и сказать, пояснив позицию.А я вроде никогда и не скрывал что у меня антипатии к скриптам писаным левой пяткой, когда параметры конфигурации надо на третьей странице колупать. У поцтера же чтобы написать три страницы в конфиг - придется проявить неслабую креативность и поднапрячь фантазию :). А еще - да, я могу не очень хотеть взаимодействвать с людьми, поведение которых мне кажется неприятным или контрпродуктивным. Это странно? Я буду объединять мои усилия с теми кто стремится к тем же целям что и я, в виде похожем на то что хочется видеть мне. Вроде бы абсолютно логично.
> Какой-то очень спорный тезис, имхо.Проверенный практикой.
> И вот вы пока, имхо, вместе с другими хейтерами кичитесь контрпродуктивным хейтерством
Чего? Вот если Вам лично двинуть монтировкой, а потом перекрыть кислород, предлагая его исключительно по трубочке в нагрузку с сероводородом -- будете "хейтером" или всего лишь справедливо возмущённым?
Будете же потом в затылке чесать -- "и как это я не подумал, cui bono".
> не допуская и мысли
Не судите по себе -- я знаю кучу людей, которым вполне нравится systemd. И некоторых, которые говорят, что код хорош, но сами почему-то ни разу не переезжают.
> Пока что я вижу что у матерых админов находится дофига упертости, ЧСВ
> и нежелания обучаться и просто допускать мысль что возможны различные варианты
> того что людям нравится. Как бы удачи в таком подходе.Тогда прекратите фекаться кидалиями в сторону, скажем, яблочников -- у них те же доводы, только сильнее.
> А еще с udev поупражнялся. Тоже вполне себе понравилась приблуда.
Угу -- http://www.reactivated.net/writing_udev_rules.html был зачитан до дыр в своё время.
Заодно вспомнил разницу между http://hacker.enacademic.com/1550/приблуда и http://argo.academic.ru/4174/приспособа 8)
> А вот например туеву хучу скриптов на пять страниц в бутовой последовательности
> ОС, с кучей грабель, никаким логгингом, пофигизмом на ошибки и прочее
> лично я у себя в системах видеть не хочу.Поелику смотрите на следствия, а не в корень, то пофигизм на ошибки увидите в иной форме, а куча грабель превратится в циклический граф грабель. Но тут пусть практика говорит :)
> А всякие рассказы про OVZ и прочее - уже не то.
Конечно, не то -- потому как просто работает.
> Вот лично я например вполне в настроении пользоваться контейнерами и VM не
> только на супер-серверах, но и вполне себе на моем десктопе. С свежим ядром.
> И желательно по дефолту. Это делает мою жизнь проще в ряде аспектов.О, а не расскажете о бытовых применениях? (что до "супер-серверов", то на бывших машинках OSDN было довольно скромное железо)
>> Можно пример антипатий _и_ необъективности? Вот некоего User294 на антипатиях и
>> необъективности замечал, о чём старался ему же и сказать, пояснив позицию.
> А я вроде никогда и не скрывал что у меня антипатии к скриптам писаным левой пяткой,Да если б только.
Так всё-таки будет пример или замнём для ясности? Просто для меня это довольно серьёзное обвинение, стараюсь такими не разбрасываться.
> Проверенный практикой.Да я заметил что вы любите делать далеко идущие выводы и потом считать себя истиной в последней инстанцией. Попутно полагая что надо с нахрапом втулить эту истину другим и что они должны быть всенепременно очень рады этому. ИМХО, скромнее надо быть.
> Чего? Вот если Вам лично двинуть монтировкой, а потом перекрыть кислород,
> предлагая его исключительно по трубочке в нагрузку с сероводородом -- будете
> "хейтером" или всего лишь справедливо возмущённым?Не вижу где Поттеринг имел такую возможность, чисто технически. Я конечно понимаю неудовольствие по поводу того что "халява кончилась". Но никто вам не давал обещаний обслуживать ваши желания вечно, в именно том формате, который удобен вам. По поводу чего я нахожу такое поведение некультурным.
Называя вещи своими именами: альты вполне могли бы развиться не хуже шапки, отрастить девелоперский штат размером "как шапка", платить этим людям зарплаты, ставить им задачи так как это видится правильным, набирая людей которые считают именно так и возьмутся эти задачи выполнять, именно так. И не иметь проблем такого плана. И тогда у вас будет моральное и фактическое право с этих людей что-то там требовать. А вот так с нахрапом качать права применительно к постронним людям - некультурно и малорезультативно. А они разве подписывались пожизненно на вас работать так как вам удобно?
> Будете же потом в затылке чесать -- "и как это я не подумал, cui bono".
Выгодно, очевидно, шапке. Было бы это не так - наверное для них было бы странно платить Поттерингу зарплату. Зачем им содержать сотрудника, деятельность которого им не требуется?
> Не судите по себе -- я знаю кучу людей, которым вполне нравится systemd.
> И некоторых, которые говорят, что код хорош, но сами почему-то ни разу не переезжают.Ну вот мне нравится системд. Не на 100%, но имхо - в целом стало лучше чем было до него. И я не понимаю таких предъяв Поттерингу. Да, он удачливый кекс и смог изменить мир. Забыв вас спросить - а можно ли ему. А он и не должен был вас спрашивать. И насколько вам будет удобно в новых реалиях... а вот это уже не его проблемы. И даже не шапкины. Они не подписывались никого пожизненно ублажать и вводить мораторий на изменения мира ради вас.
И да, стандарты задают те кто пишет код. Так сделал Торвальдс. На него порой шипят бсдшники и ругался Таненбаум. Но теперь он сила и с ним считаются. Совершенно добровольно. Хоть некоторые наверняка до сих пор плюются на гудение в голове от внезапно прилетевшего х.з. откуда лома. Ну вот и Поттеринг не имел никаких технических возможностей кому-то что-то навязать. У него нет роты гестаповцев чтобы кого-то затаривать монтировкой.
Почему бы не признать очевидное? Многим системд понравился. Судя по дебиану - большинству. Ну и вообще, как вы там в тредах о политике рассказывали? Меньшинство можно прокатить ради большинства, так? Ну вот у ВАС будет замечательный шанс оценить на своей шкуре как это ощущается. Хотя тут даже честнее как-то: возможность писать код так как вы считаете нужным у вас вроде никто не забирал. А если попробовать отфоркать государство - по чайнику в два счета настучат, оптом и в розницу.
> Тогда прекратите фекаться кидалиями в сторону, скажем, яблочников -- у них те
> же доводы, только сильнее.Разница в отношении ИМХО проистекает по вполне характерной границе водораздела, из-за которой мы тут и встречаемся. Называется "наличие исходных текстов" (под опенсорсной лицензией).
Лично я считаю что шанс изменить мир и идти своей дорогой для тех кому очень хочется - должен быть. Наличие исходных текстов - такой шанс дает. Проприетарщики мне не нравятся в основном тем что отбирают этот шанс почем зря, на ровном месте. Но шанс не является гарантией или обязательством того что будет именно так, а не иначе. И никто не обещал что все это будет просто. В моем понимании, главное свинство проприетарщиков - это когда они этот шанс отбирают, зажав сорцы. А то что шанс реализуют не все... ну вот те кто смог - те имхо и достойны получать будущее удобным для себя. Потому что они его и формировали. Своим въе...
А если очень хочется попинать меня в каком-то таком контексте, на хитрых граничных условиях - лучше, наверное, вспомнить мое отношение к андроиду. Так можно попробовать нащупать какие-то еще линии водораздела кроме наличия/отсутствия сорца. Поскольку вы наверное согласитесь что опенсорс бывает разный. Но замечу что хотя я не симпатизирую андроиду и мне нравится maemo, я вовсе не считаю что гугл должен бросить все и делать мне удобно, догадываясь что мечтать не вредно :).
> Угу -- http://www.reactivated.net/writing_udev_rules.html был зачитан до дыр в своё время.
По крайней мере, почитав это + посмотрев udev-adm monitor, через 10 минут я на нем изобразил то что хотел, хотя впевые в жизни туда сунулся. В наименее кривом виде из всех которые были до этого. Получилось результативно и безглючно. Скажу ка я спасибо Mihail Zenkov за то что он подал идею. Хоть это и не по части usb-клавиатур было...
P.S. Если бы udev писали НеФанаты поттеринга которым нравится sysv init - там вместо правил были бы имхо сотни скриптов и я бы озверел задолго до того как сделал то что хотел. Бонусом я теперь знаю как приветствовать удавом тех кто попробует сосватать мне "предсказуемые" имена и-фейсов вида en1p0s4 :)
> а куча грабель превратится в циклический граф грабель.
Это так. Но вы умолчали о том что альтернативой в sysv init были вообще все фокусы которые может выкинуть тюринг-полная программа. Среди них кроме всего прочего есть и то самое время выполнения программы, и то самое отсутствие решения.
> Но тут пусть практика говорит :)
Разумеется. И говоря за себя, с практической точки зрения я для конфигурации предпочту конфиги на 5 строк, а не тюринг-полные программы на каждый пшик, даже там где это нафиг не упало.
> Конечно, не то -- потому как просто работает.
Понятия о простом, как видим, у всех разные.
> О, а не расскажете о бытовых применениях?
Например для меня вполне характерно если у меня между делом запущено например несколько KVMных VM. Причины по которым они запускаются бывают разные. Можно отпилить некий сервис от системы, лишив его возможности шариться по моим данным, даже в случае взлома будет солидный барьер на пути атакующих. В дефолтном окружении которое довольно просто мониторить на предмет изменений и подозрительных действий. Можно погонять вон ту ОС на посмотреть без риска что-то сломать в своей системе. Можно посмотреть "а что будет, если..." с возможностью отмотать назад за ...цать секунд, если результат не понравился. Можно не загаживать себе основную систему софтом "на посмотреть", рискуя "хвостами после сноса" или "нежелательным поведением" и посмотреть в VM. Можно обкатать нестандартный сетевой конфиг, который из реальных железяк набирать было бы долго, дорого и утомительно. Это будет достаточно приблизительно. Но познакомиться с штуками типа tc в таком виде будет попроще. А если понравится - можно сделть снапшоты и сохранить "конфиг для сетевых экспериментов". Он будет приводиться в это состояние за несколько минут. На реальных железках возни будет сильно больше. Можно какую-нибудь экзотичную сборочную среду гонять, без замусоривания основной системы, etc.
Контейнеры для части этих вещей в принципе тоже сгодились бы, имеючи очевидный плюс в виде куда более скромного оверхеда и минус в виде более хилой изоляции. Со снапшотами в btrfs можно сделать неплохой аналог снапшотов VM, только CoW - не в диске-файле, а сразу в ФС, стало быть минус уровень абстракций и парсинга блоков. Ну и всякие тонкие моменты по части изоляции. Которая в майнлайне до сих пор не 100% полная. Правда жизни такова что в майнлайне контейнеры не на 100% допилены и потому годятся для изоляции "не слишком враждебного" софта.
>> А я вроде никогда и не скрывал что у меня антипатии к скриптам писаным левой пяткой,
> Да если б только.Люди - достаточно сложные существа. "Только" было бы слишком просто :P.
> Так всё-таки будет пример или замнём для ясности? Просто для меня
> это довольно серьёзное обвинение, стараюсь такими не разбрасываться.Так это не обвинние лично вас. Это скорее общее описание ситуации "на планете".
Ну вот например, есть такая программа - 3proxy. Но она есть не во всех дистрах. Как минимум в дебиане и убунте ее нет. А жаль - полезный "swiss army knife" в своем роде. Но компилится просто. А с учетом того что порой имеет смысл брать -dev версию, и подавно. А вот ее дефолтный инит-скрипт из тарбола - ужасен. О чем очень быстро узнаем при попытке настроить автозапуск. Systemd юнит я в желаемый вид отрихтую сильно быстрее, при прочих равных. Это - одна программа. А таких программ в природе десятки тысяч. А иногда мне например не нравится как себя ведет майнтайнерский дефолт. И в случае системд мне будет как-то легче и быстрее перенастроить это, да и мегахудожеств там будет поменьше и только при реально сильной нужде.
Конкретно альт в этом плане сделал менее ужасно чем у других, но ... с точки зрения админа ценность знаний о одном местечковом дистре - невысокая. Code reuse и knowledge reuse с другими дистрами - отсутствует. Распостраненность дистра - скромная. Другие дистры такой подвид инициализации не подхватили. Ну и с чисто прагматической точки зрения мне в конфиге на 5 строк сильно быстрее и проще разобраться чем в куче скриптов.
В этом месте можно полить меня помоями за мои персональные предпочтения, но единственное чего так можно добиться - разве что дополнительной порции антипатий. Поэтому предлагаю посчитать что мне удобнее так как в systemd и принять это как факт.
Грубо говоря, когда я вижу системд, какая-нибудь кастомная сетевая хотелка вида "хочу запуститься всенепременно ДО network-manager, чтобы сделать <нечто> с <вон тем интерфейсом>, до того как network manager его оседлает" - решается относительно очевидно для меня. И не очень криво. А то что sysv init по этому поводу предлагает - "нет слов, одни междометия". Ну то-есть при сильном желании, конечно, и он что-то может. Но такое непотребство, имхо, как-нибудь без меня.
> какая-нибудь кастомная сетевая хотелка вида "хочу запуститься всенепременно ДО network-manager, чтобы сделать <нечто> с <вон тем интерфейсом>, до того как network manager его оседлает" - решается относительно очевидно для меня. И не очень криво. А то что sysv init по этому поводу предлагает - "нет слов, одни междометия".Ну, объективности ради, в линейном, неотпараллеленом SysV подобная задача - это ровно один chkconfig --level ...
Вообще, я не противник systemd. Собственно, мне уже некоторое время на линукс - всё равно. То есть, он всё ещё остаётся моей рабочей системой, мне на нём действительно удобнее, чем на винде или маке, но интересы ушли в сторону, поэтому как "оно" работает внутри мне становится интересно, только в тот момент, когда "оно" перестаёт работать. И вот здесь SysV vs systemd можно сравнить с классическим дизелем против дизеля современного, с наддувом и прочими эко-режимами. Спору нет, когда топливо хорошее, дорога прямая и машина новая, так современный дизель - это просто песня! "И кормить не надо!" А когда заправляться надо всяким гуано, и, главное, надо иметь возможность починиться при помощи монтировки и такой-то матери, то тут начинаются вопросы.
Например, до 219-ой версии у меня на localhost не взлетал journald в ходе штатного бутапа. Причем, сервисов на машине - хрен да маленько, говорю ж, localhost, просто набор файловых систем несколько причудливее обычного - тут тебе и отдельные разделы для /usr и /var, и софтовые рейды, и btrfs и т.п. В общем-то, ничего сложного, но вот поди ж ты, journald можно запустить только руками, после того, как вся система прогрузится и ты сможешь в консольке залогиниться. И очистка временных файлов не отрабатывает, как дóлжно. А поскольку система при этом находится в стадии "непрогрузившейся", то дефолтная конфигурация системд оставляет записочку pam-nologin'у и восстановить работоспособность ssh после перезагрузки можно только с локальной консольки.
И, понятное дело, поскольку это загрузка, да ещё и загрузка параллельная, то понимать, что где в коде рэйсится (а проблемы именно в рэйсе) - это задача, ну, скажем так, не вполне тривиальная. Вот и спрашивается в задаче: что лучше для такого енд-лузера, как я - тупой и неприхотливый SysV или претендующий на элегантность systemd?
> Да я заметил что вы любите [...] считать себя истиной в последней инстанции.Если так кажется -- значит, моя недоработка, поскольку сам порой вполшутки отрекомендовываюсь "непрофессионал широкого профиля", т.е. _заведомо_ не последняя инстанция. :)
> Попутно полагая что надо с нахрапом втулить эту истину другим
Пока нахрапом втуливаете "истину systemd" Вы, ещё несколько столь же обрадованных, но грамотных людей (которые по крайней мере способны внятно объяснить, что именно пришлось по вкусу) -- и стопка мутных анонимов, напоминающих шляпоботов под крылышком условного пети леменкова. Последнее изрядно напрягает.
> Не вижу где Поттеринг имел такую возможность, чисто технически.
В редхате.
> По поводу чего я нахожу такое поведение некультурным.
Какое -- когда ломают созданную усилиями далеко не только редхата и тем более Леннарта экосистему? Или когда *вдруг* некоторые этому удивляются вслух?
> Называя вещи своими именами: альты вполне могли бы развиться не хуже шапки,
> отрастить девелоперский штат размером "как шапка", платить этим людям зарплаты,
> ставить им задачи так как это видится правильным, набирая людей которые считают
> именно так и возьмутся эти задачи выполнять, именно так.Нет. Могу разобрать заблуждение на пальцах, но в два хода переходим к макроэкономике и геополитике. Поэтому здесь лучше завязать узелок и вернуться к вопросу на следующем витке, а он будет.
>> Не судите по себе -- я знаю кучу людей, которым вполне нравится systemd.
> Забыв вас спросить - а можно ли ему.Написано было для Вас -- надеюсь, не будете забывать спрашивать, а можно ли высказываться за меня таким или сяким образом. Я ж не вкладываю свои соображения, представляя их как Ваши мысли или предпочтения (а если где так и сделал -- значит, неправ, надо исправлять).
> Они не подписывались никого пожизненно ублажать и вводить мораторий
> на изменения мира ради вас.Ну, what goes around comes around.
> Ну вот и Поттеринг не имел никаких технических возможностей кому-то что-то навязать.
> У него нет роты гестаповцев чтобы кого-то затаривать монтировкой.Имел и есть. То, что за Вами ещё не пришли -- не значит того, что эт самое гестапо уже не приходит за другими. Собственно, вспомните соответствующую критику Линуса и Алана.
> Почему бы не признать очевидное? Многим системд понравился.
> Судя по дебиану - большинству.Опять передёргиваете. Не хочу политизировать, но вот на таких внушаемых "умных" и строят катастрофы.
> Ну и вообще, как вы там в тредах о политике рассказывали?
> Меньшинство можно прокатить ради большинства, так?Сложнее -- смотря по взаимозависимостям между меньшинством и большинством. Из тех меньшинств, над которыми в этом ключе размышлял, замечены созидательные (не путать с "креативными") и паразитические, среди прочих. Ну, глупо в организме ставить на одну доску глаз и опухоль.
> Ну вот у ВАС будет замечательный шанс оценить на своей шкуре как это ощущается.
Знаете, я не первый десяток лет в различных созидательных меньшинствах, чтоб таких шансов был за спиной вагон и маленькая тележка. :)
>> Тогда прекратите фекаться кидалиями в сторону, скажем, яблочников -- у них те
>> же доводы, только сильнее.
> Разница в отношении ИМХО проистекает по вполне характерной границе водоразделаО, вот и Вы о том же -- о критериях и целеполагании меньшинства.
> Называется "наличие исходных текстов" (под опенсорсной лицензией).
Вы это по Перенсу или в качестве удобного краткого штампа? Старался избегать путаницы "opensource" с "free software" ещё до того, как со Столманом тортик чаёвничали -- это же дырка, которую уже успешно эксплойтили.
> Проприетарщики мне не нравятся в основном тем что отбирают этот шанс почем зря,
> на ровном месте.Скажите мне, Unity -- свободная программа или проприетарная? Если свободная, почему её нет в том же дебиане? (и следующим же ходом намёк возвращается к шляпе, да)
> А если очень хочется попинать меня в каком-то таком контексте, на хитрых
> граничных условиях - лучше, наверное, вспомнить мое отношение к андроиду.
> Так можно попробовать нащупать какие-то еще линии водораздела кроме
> наличия/отсутствия сорца.Пинать цели нет, а скорее сообща вырабатывать это самое понимание, включая и критерии, и границы. Ровно потому, что в два глаза видишь лишь с одной стороны.
> По крайней мере, почитав это + посмотрев udev-adm monitor, через 10 минут
> я на нем изобразил то что хотел, хотя впевые в жизни туда сунулся.Так не зря несколько лет тому на udev попереписывали вроде как все ныне живые генераторы initrd.
> P.S. Если бы udev писали НеФанаты поттеринга которым нравится sysv init -
Брр, Вы вообще в курсе, что udev был вмержен в systemd, причём с признаками враждебного поглощения (безапелляционное выбрасывание функциональности)?
> там вместо правил были бы имхо сотни скриптов
А там сотни не нужны, посмотрите ранние версии.
$ fgrep -rl /bin/sh /lib/udev
/lib/udev/write_net_rules
/lib/udev/rules.d/80-udisks2.rules
/lib/udev/write_cd_rules
/lib/udev/kpartx_id> Бонусом я теперь знаю как приветствовать удавом тех кто попробует сосватать мне
> "предсказуемые" имена и-фейсов вида en1p0s4 :)Так это же Кей с Леннартом и есть, насколько помню. В альте, кстати, трудами майнтейнера и сейчас есть пакетик udev-rule-generator-net (а в mkimage-profiles -- его поддержка), который позволяет всё так же развешивать eth* или там int/ext по тем же критериям.
А генератор "предсказуемых имён" для фермы управления кластером дизайнил и писал где-то в 2010, что ли -- там было осмысленно.
>> а куча грабель превратится в циклический граф грабель.
> Это так. Но вы умолчали о том что альтернативой в sysv init
> были вообще все фокусы которые может выкинуть тюринг-полная программа.Так об этом Вы уже всё сказали :)
> Среди них кроме всего прочего есть и то самое время выполнения программы,
> и то самое отсутствие решения.Для этого больше постараться надо, т.к. среднему разработчику очевидней -- бОльшая часть кода и ситуации на ладони, чем в асинхронной системе.
Вчера вечером слушал балалайку Архиповского и размышлял, как бы Вам объяснить, что в мире есть не только лабухи и их портянки на чём угодно -- хоть на шелле, хоть маслом.
Помнится, как-то упоминал про http://altlinux.org/control и мог предлагать глянуть "4K-демку": http://git.altlinux.org/gears/c/control.git?p=control.git;a=... -- но код, включая объём, трудней оценить, если не попользоваться самой софтинкой в быту. А ведь он интересный и очень компактный.
>> О, а не расскажете о бытовых применениях?
> Например для меня вполне характерно если у меня между делом запущено например
> несколько KVMных VM. Причины по которым они запускаются бывают разные. [...]Так это почти всё именно про VM, а не про контейнеры.
> Контейнеры для части этих вещей в принципе тоже сгодились бы, имеючи очевидный
> плюс в виде куда более скромного оверхеда и минус в виде более хилой изоляции.В основном для недоверенного кода и проверки софта, может, ещё для части сетевых опытов.
> Правда жизни такова что в майнлайне контейнеры не на 100% допилены
> и потому годятся для изоляции "не слишком враждебного" софта.Угу.
>> Так всё-таки будет пример или замнём для ясности? Просто для меня
>> это довольно серьёзное обвинение, стараюсь такими не разбрасываться.
> Так это не обвинние лично вас. Это скорее общее описание ситуации "на планете".Принято.
> Ну вот например, есть такая программа - 3proxy. Но она есть не
> во всех дистрах. Как минимум в дебиане и убунте ее нет.Повесьте просьбу собрать?
> А вот ее дефолтный инит-скрипт из тарбола - ужасен.
Они тем ужасней, чем больше поддерживаемых сильно разных систем наросло. В том году "порадовался" тому, что узрел в тарбольных скриптах 389ds -- там нетскейп и, кажется, ещё сверху сан потоптался...
> Systemd юнит я в желаемый вид отрихтую сильно быстрее, при прочих равных.
В альте типичный шаблон выглядит так: http://git.altlinux.org/gears/s/service.git?p=service.git;a=... -- думаю, можно для тривиальных случаев свести к чему-то вроде
#!/bin/sh
# template Summary of the service.
# chkconfig: - 90 10
. /путь/к/обёртке
Exec=template
User=_nonroot> Это - одна программа. А таких программ в природе десятки тысяч.
Что, прям-таки сервисов?
> Конкретно альт в этом плане сделал менее ужасно чем у других,
А в каком месте у нас вообще ужасно в этом плане? Вдруг поправимо.
> но... с точки зрения админа ценность знаний о одном местечковом дистре - невысокая.
Зависит от целеполагания -- для фрилансера это так, для админа на месте гораздо важней трудозатраты на подъём и сопровождение, как уже говорил и буду говорить.
> Code reuse и knowledge reuse с другими дистрами - отсутствует.
Отнюдь. Для понимания этого дебианщику должно быть достаточно глянуть по ссылке на template выше. :) А если отсталые дистрибутивы не берут код или знания -- ну что ж их, демократизировать, что ли? Взять тот же control(8) -- изумительная по полезности штука, простая как полено, и где она ещё, кроме как в Owl?
> Поэтому предлагаю посчитать что мне удобнее так как в systemd и принять это как факт.
Так Вы это и так уже не раз озвучили, что ж не принять? Не мной свободная воля дана, не мне её и оттяпать пытаться.
> А то что sysv init по этому поводу предлагает - "нет слов, одни междометия".
Тоже мне бином Ньютона -- помимо сказанного Лёшей рядом, смотрим в http://git.altlinux.org/gears/N/NetworkManager.git?p=Network... (или прям в /etc/init.d/NetworkManager) насчёт chkconfig, задаём в нужном инитскрипте старт лексикографически чуть раньше (т.е. <12 или 12 с <N, последнее менее предпочтительно).
Да, если циферка старта NM вдруг будет изменена ещё ниже -- придётся откорректировать. Зато линейный порядок без циклов.
Ох какой сочный комментарий, сразу видно, человек может и любит поспорить, разрешите пристроиться.> Какое -- когда ломают созданную усилиями далеко не только редхата и тем
> более Леннарта экосистему? Или когда *вдруг* некоторые этому удивляются вслух?Они всё-таки на базе этой экосистемы пилят новую, с доп. фичами, свистелками и перделками, можно их нелюбить, считать архитектурно неправильными, но основная проблема что "нет пророка в своём отечестве" - кто бы показал как надо. А то тем, кому фичи нужны (вроде cgroups с отслеживанием всех потомков демона, старты с зависимостями с Ъ параллелизмом) приходится сидеть на systemd со всеми его цветочками и иголками одновременно.
>> Называя вещи своими именами: альты вполне могли бы развиться не хуже шапки,
>> отрастить девелоперский штат размером "как шапка", платить этим людям зарплаты,
>> ставить им задачи так как это видится правильным, набирая людей которые считают
>> именно так и возьмутся эти задачи выполнять, именно так.
> Нет. Могу разобрать заблуждение на пальцах, но в два хода переходим
> к макроэкономике и геополитике. Поэтому здесь лучше завязать узелок и
> вернуться к вопросу на следующем витке, а он будет.Ну помечтать-то не мешайте. Вот если бы тотальный напиллинг не мешал бы финансировать отечественное развитие ОС (с общим апстримом на весь мир, но с софтом решающим конкретные проблемы конкретных контор, например: сборка для школ, сборка для судов, сборка для военных, сборка для мед. учереждений и т.д.). Собственно если весь тот поток бабла, который уходит в карман МС и прочим проприетарным конторам влить в свой опенсорс (разработка под заказ для государства с открытыием исходников для всех, чтобы можно было принимать от населения исправления), то сейчас бы Россия экспортировала бы свой опыт и спецов за большое бабло наружу.
>> Ну вот и Поттеринг не имел никаких технических возможностей кому-то что-то навязать.
>> У него нет роты гестаповцев чтобы кого-то затаривать монтировкой.
> Имел и есть. То, что за Вами ещё не пришли --
> не значит того, что эт самое гестапо уже не приходит за
> другими. Собственно, вспомните соответствующую критику Линуса и Алана.Ну учтём, что Линукса не критикует только ленивый. Леннарта и прочих тоже. Собственно, добро пожаловать в человеческое общество где всех хлебом не корми - дай продуктами жизнедеятельности ближнего своего вымазать.
>> Почему бы не признать очевидное? Многим системд понравился.
>> Судя по дебиану - большинству.
> Опять передёргиваете. Не хочу политизировать, но вот на таких внушаемых "умных"
> и строят катастрофы.Давайте договоримся что результаты показали, что большинству мэнтейнеров и девелоперов всё равно и катастрофу в лице systemd видит меньшинство. Так ближе к истине? И можно обойтись без тайных тамплиеров, подтасовок и родственников в заложниках у тех. коммитета Дебиана.
>> Называется "наличие исходных текстов" (под опенсорсной лицензией).
> Вы это по Перенсу или в качестве удобного краткого штампа? Старался
> избегать путаницы "opensource" с "free software" ещё до того, как со
> Столманом тортик чаёвничали -- это же дырка, которую уже успешно эксплойтили.
>> Проприетарщики мне не нравятся в основном тем что отбирают этот шанс почем зря,
>> на ровном месте.
> Скажите мне, Unity -- свободная программа или проприетарная? Если свободная, почему
> её нет в том же дебиане? (и следующим же ходом намёк
> возвращается к шляпе, да)Свободная. Парирую ваш вопрос так: если она проприетарная, то почему она есть в OpenSUSE? Ответ простой - кто-то захотел под себя допиливать и патчить, кто-то не захотел. Любой софт надо подпиливать под дистр. Особенно крупные штуки вроде ДЕ. Особенно если это ДЕ - на самом деле другой ДЕ, в кучей патчей в общем коде.
>> По крайней мере, почитав это + посмотрев udev-adm monitor, через 10 минут
>> я на нем изобразил то что хотел, хотя впевые в жизни туда сунулся.
> Так не зря несколько лет тому на udev попереписывали вроде как все
> ныне живые генераторы initrd.
>> P.S. Если бы udev писали НеФанаты поттеринга которым нравится sysv init -
> Брр, Вы вообще в курсе, что udev был вмержен в systemd, причём
> с признаками враждебного поглощения (безапелляционное выбрасывание функциональности)?udev вроде как остался без завязки на systemd хоть и переехал в репу systemd (его всё ещё можно было запускать самостоятельно). Если что-то изменилось - поправьте.
>> Бонусом я теперь знаю как приветствовать удавом тех кто попробует сосватать мне
>> "предсказуемые" имена и-фейсов вида en1p0s4 :)
> Так это же Кей с Леннартом и есть, насколько помню. В
> альте, кстати, трудами майнтейнера и сейчас есть пакетик udev-rule-generator-net (а в
> mkimage-profiles -- его поддержка), который позволяет всё так же развешивать eth*
> или там int/ext по тем же критериям.Есть точно так же параметр ядра для такого же поведения.
>> А то что sysv init по этому поводу предлагает - "нет слов, одни междометия".
> Тоже мне бином Ньютона -- помимо сказанного Лёшей рядом, смотрим в http://git.altlinux.org/gears/N/NetworkManager.git?p=Network...
> (или прям в /etc/init.d/NetworkManager) насчёт chkconfig, задаём в нужном инитскрипте
> старт лексикографически чуть раньше (т.е. <12 или 12 с <N, последнее
> менее предпочтительно).
> Да, если циферка старта NM вдруг будет изменена ещё ниже -- придётся
> откорректировать. Зато линейный порядок без циклов.Ну опять или выстраиваем всех в линейку или строим граф и параллелизуем по нему. 2 разных подхода в корне. Можно спорить до кровавых соплей о том что лучше.
> сразу видно, человек может и любит поспорить, разрешите пристроиться.Так цель-то не спор ради спора, а сверить соображения -- вдруг чего ещё выяснится.
>> Какое -- когда ломают созданную усилиями далеко не только редхата и тем
>> более Леннарта экосистему? Или когда *вдруг* некоторые этому удивляются вслух?
> Они всё-таки на базе этой экосистемы пилят новую, с доп. фичами, свистелкамиЭто понятно, вот только наблюдаются признаки приватизации этой новой экосистемы. Одним из совершенно чётких звоночков было поспешное зачисление всех неслухов в "маргиналы" (это ещё до того, как сломали об колено дебиановскую демократию).
> Ну помечтать-то не мешайте. Вот если бы тотальный напиллинг не мешал бы
> финансировать отечественное развитие ОС (с общим апстримом на весь мир, но [...])А толку тут мечтать, если можно делать? Правда, золотых дождей и тем более парашютов не предвидится, но это уж кто что ищет.
>>> Судя по дебиану - большинству.
>> Опять передёргиваете.
> Давайте договоримся что результаты показали, что большинству мэнтейнеров
> и девелоперов всё равно и катастрофу в лице systemd видит меньшинство....что как раз обычное явление. Впрочем, про другие характерные звоночки тоже не раз уж в таких темах писал, так что тут польза была бы разве что собрать критику на вики-страничку (искренне радеющие за systemd могли бы пользоваться ей как TODO).
>> Скажите мне, Unity -- свободная программа или проприетарная?
> Парирую ваш вопрос так: если она проприетарная, то почему она есть в OpenSUSE?Не парировали: http://pkgs.org/opensuse-factory/opensuse-non-oss/
> Ответ простой - кто-то захотел под себя допиливать и патчить, кто-то не захотел.
> Любой софт надо подпиливать под дистр.Это софт, который требует подпиливания под себя дистра. Формально свободный, да.
>>> Какое -- когда ломают созданную усилиями далеко не только редхата и тем
>>> более Леннарта экосистему? Или когда *вдруг* некоторые этому удивляются вслух?
>> Они всё-таки на базе этой экосистемы пилят новую, с доп. фичами, свистелками
> Это понятно, вот только наблюдаются признаки приватизации этой новой экосистемы. Одним
> из совершенно чётких звоночков было поспешное зачисление всех неслухов в "маргиналы"
> (это ещё до того, как сломали об колено дебиановскую демократию).Тут как с любым другим проектом - как только кол-во непринятых полезных патчей превысит критическую массу, проект рискует уплыть. Так и получается: или плывёшь со всеми по пути или гребёшь сам за всех. Либру форкнули из-под Оракла, сейчас плывёт неплохо. Та же судьба легко может постичь и systemd при первых признаках "приватизации". А уж про записывания в секты - онлайн коммьюнити не сэры, попивающие виски с сигарой, кроют друг друга скорее уж как свора сапожников. Достаточно тему vim vs emacs почитать чтобы понять что запишут сразу, легко и быстро независимо ни от чего и куда угодно.
>> Ну помечтать-то не мешайте. Вот если бы тотальный напиллинг не мешал бы
>> финансировать отечественное развитие ОС (с общим апстримом на весь мир, но [...])
> А толку тут мечтать, если можно делать? Правда, золотых дождей и
> тем более парашютов не предвидится, но это уж кто что ищет.На бутерброд с колбасой бы хватало - был бы другой разговор. А то воспоминания о школьном линуксе как-то не очень на позитивный лад настраивают...
>>>> Судя по дебиану - большинству.
>>> Опять передёргиваете.
>> Давайте договоримся что результаты показали, что большинству мэнтейнеров
>> и девелоперов всё равно и катастрофу в лице systemd видит меньшинство.
> ...что как раз обычное явление. Впрочем, про другие характерные звоночки тоже
> не раз уж в таких темах писал, так что тут польза
> была бы разве что собрать критику на вики-страничку (искренне радеющие за
> systemd могли бы пользоваться ей как TODO).Так и почему бы нет? Пульсаудио тоже принимали в штыки, потом допилили и вроде даже едят признав что местами оно нужно (а местами - нет).
>>> Скажите мне, Unity -- свободная программа или проприетарная?
>> Парирую ваш вопрос так: если она проприетарная, то почему она есть в OpenSUSE?
> Не парировали: http://pkgs.org/opensuse-factory/opensuse-non-oss/Оно всё-таки в ОСС репах, так что давайте, засчитаем за свободное. Всякие tux-on-ice тоже в ванильных дистрибутивах почти не встречаются, от чего не становятся несвободными.
>> Ответ простой - кто-то захотел под себя допиливать и патчить, кто-то не захотел.
>> Любой софт надо подпиливать под дистр.
> Это софт, который требует подпиливания под себя дистра. Формально свободный, да.Он действительно свободный. Неудобный и мешающий другим - но сорц есть и модифицировать его никто не запрещает. Всякие ffmpeg и libav тоже во время разборок друг другу мешали (сейчас вроде как, слава богу, один из них почти околел)
> Идея сталкивается с вопросом: ну и нафига это надо, если и старое работает отлично.Как человек, довольно много ковырявшийся в куче костылей, которые собирательно обзывают "SysV init" (хотя на самом деле, sysvinit - это /sbin/init и вспомогательные программы типа /sbin/shutdown, самостоятельно загрузить систему не способные), могу точно сказать - нет, далеко не всегда работат, и почти всегда - не отлично.
> Начальная реализация: не очень-то и работает. Внедряли вот в Debian, обещали загрузку
> ускорить (да, да, поттеринг настаивает, что это побочный результат), а в
> итоге что? Загрузка в полтора раза замедлилась по сравнению с sysvinit.Это у вас. А у меня, например, ускорилась раз в пять - теперь не надо минуту ждать, пока какой-нибудь ntpd осознает себя и изволит дать отмашку на продолжение загрузки.
> Заинтересованная компания Red Hat: заинтересована в том, чтобы установить вендор-лок на
> свои разработки. Кому, кроме неё, это надо?Какой вендор-лок под GPL? Простите, вы в своем уме?
Если разработчики systemd (к слову, не только редхад, но и интел) начнут делать что-то, неприятное для сообщества, его просто форкнут.
Пока, судя по никому не интересным выкидышам (например, uselessd), сообщество в целом не имеет ничего против systemd. А те, кто имеют, как правило, не являются частью сообщества.
> Какой вендор-лок под GPL? Простите, вы в своем уме?Элементарный, Ватсон.
> Консорциум создается не на пустом месте, а когда уже есть какая-то идея, начальная реализация и хотя бы один заинтересованный разработчик.man PowerPC
> А вот руководи разработкой systemd консорциум из независимых компаний, то глядишь получилась
> бы офигенная унифицированная прослойка между ядром и прикладным софтом.Это каких независимых? Поясните плз!
Независимых друг от друга.
> Независимых друг от друга.А как можно не зависеть друг от друга, разрабатывая опенсорсный проект? Или вы про кучку прориетарщиков, которые независимо от друг друга в 10 разных гаражах варят 10 разных великов из самых разных труб?
Очевидно, таковых компаний можно набрать на кикстартере. Независимости там - полные штаны.
> Очевидно, таковых компаний можно набрать на кикстартере. Независимости там - полные штаны.Независимые, только с пустым карманом.
> Независимые, только с пустым карманом.А это уже вопрос в том кому и насколько данные работы нужны. Было бы кому-то нужно - они бы поддержали звонкой монетой, вероятно.
"designed by committee"
Скорее пара десятков мелких компаний и отдельных разработчиков реализуют отдельные компоненты (как и должно было бы быть с самого начала), вроде uselessd и подобного.
К сожалению, uselessd полностью оправдал свое название - оказался никому не нужен и загнулся.
И это всего спустя день после передачи gudev от systemd к GNOME. Разработчики - молодцы, хорошая работа.
Доступ к геолокации, сканеру отпечатков пальцев, акселерометру есть?
По ссылке не ходи, комментарий пиши?С https://github.com/hadess/iio-sensor-proxy
> IIO accelerometer sensor to input device proxy
> accelerometer sensor
> accelerometerК отпечаткам пальцев доступа нет, т.к. давать такой же доступ, как к акселерометру и сенсору света было бы несекьюрно (приложение подписалось на показания сканера, а тут пользователь решил разлочить экран.. приложение похитило отпечатки пальцев?). Для отпечатков сто лет уже есть http://www.freedesktop.org/wiki/Software/fprint/fprintd - тоже через D-Bus, но о секьюрити позаботились и сделали нормально.
Геолокация это вообще-то не сенсор вообще, а API на базе нескольких сенсоров (включая GPS, Wi-Fi точки в окрестности, GSM-модуль и т.д.). Геолокацию через D-Bus в гноме представляет http://www.freedesktop.org/wiki/Software/GeoClue/
> Геолокация это вообще-то не сенсор вообще,А GPS приемник - чем не сенсор?
Это сенсор, но его данные не слишком полезны - он не дает показаний, если нет спутников в прямой видимости, долго инициализируется, если ему не подсказать, где мы находимся и прочие проблемы. Поэтому в жизни используется сложная схема со сравнением списка Wi-Fi точек и мощности их сигналов с БД, показывающей расположение различных Wi-Fi точек, получением данных о базовой станции GSM и выяснении ее расположения, скармливание уточняющих данных GPS-у (A-GPS) и комбинация данных от GPS и всего этого, чтобы получить координаты с приемлимой точностью. Кроме того, так часто можно довольно точно определить позицию даже в помещении, при отсутствии показаний от GPS. А для стационарных компьютеров есть свои способы, например примерное определение положения по внешнему IP-адресу.Поэтому на практике с GPS'ом напрямую программы не работают, а хотят специальные Geolocation API, который совместит показания разных способов определения положения для них и отдаст им результат. И который будет работать даже если GPS'а нет вообще или он сейчас не дает достаточных данных. Никто не хочет завязывать логику в программе на прямую видимость спутников... поэтому определение положения в общем случае не завязано на GPS-сенсор и не требует его в обязательном порядке.
> Это сенсор, но его данные не слишком полезны -А вот давай ты за меня не будешь решать - какие мне показания полезны.
> он не дает показаний, если нет спутников в прямой видимости,
На самом деле - очень зависит от. Хороший модуль с хорошей антенной нынче может не терять спутники даже в здании. Как миниму на горячую. При холодном старте чувствительность ниже, там да, возможны варианты. Поэтому соверменный подход - стартануть 1 раз а потом иногда, не реже чем раз в полчаса, включать активный режим (чтобы поймать изменения альманаха/эфемериса).
> долго инициализируется,Порядка 35 секунд на холодную. Хотя с плохой антенной и в подвале может быть и бесконечность, ессно.
> если ему не подсказать, где мы находимся и прочие проблемы.
Тем не менее, программу может интересовать и вполне детальная информация о состоянии спутниковых группировок, уровнях сигналов и прочая. Вот лично меня эта инфомация интересует. Потому что HDOP и VDOP из приемника - это конечно отлично, НО понимание уровней сигнала позволяет намного точнее понимать насколько достоверы показания приемника, HDOP и VDOP половиной приемников заполняются очень отфонарно, так что истинные координаты != GPS координаты +\- (HDOP, VDOP).
> Поэтому в жизни используется сложная схема со сравнением списка Wi-Fi точек
> и мощности их сигналов с БД, показывающей расположение различных Wi-Fi точек,Все это требует доступ в сеть, который есть далеко не везде. И для меня такая активность вообще является нежелательной - для этой информации надо информировать чужой сервер где я находусь. Мне колоколец отзванивающий АНБ мои координаты как-то ни к чему.
> определить позицию даже в помещении, при отсутствии показаний от GPS. А
> для стационарных компьютеров есть свои способы, например примерное определение
> положения по внешнему IP-адресу.У GPS есть жирный плюс: он абсолютно автономен. Поэтому работает даже у черта на рогах, где сетей нет даже в проекте. И не нагибает мое приваси. А точность всех этих вайфаев и сигнала БС - плюс минус километр. Маловато для навигации. Но достаточно для понимания какие места посещает индивид. Себе такое западло оставьте с вашими спайварными апи.
> Поэтому на практике с GPS'ом напрямую программы не работают, а хотят специальные
> Geolocation API, который совместит показания разных способов определения положения для
> них и отдаст им результат.Я не заинтересован в том чтобы программы без спроса слали мои координаты на какие-то левые сервера, извините.
> определение положения в общем случае не завязано на GPS-сенсор и не
> требует его в обязательном порядке.А не пойти ли вам н...й, вебдванольные пудаки? Вы и из навигации спайварь для анб умудрились сделать.
>> Это сенсор, но его данные не слишком полезны -
> А вот давай ты за меня не будешь решать - какие мне показания полезны.Ребята, вы о чём вообще? Посмотрите на это IIO, что ли, и как из него предлагается выковыривать эти самые показания.
> Ребята, вы о чём вообще? Посмотрите на это IIO, что ли,
> и как из него предлагается выковыривать эти самые показания.Я так понимаю что это в основном про всякие сенсоры на I2C и прочие подобные штуки. И если уж на то пошло, GPS-модуль на UART (или даже виртуальном UART over USB) - не очень далеко от подобных датчиков ушел.
> Я так понимаю что это в основном про всякие сенсоры на I2C и прочие подобные штуки.Именно: http://cateee.net/lkddb/web-lkddb/IIO.html -- и по сравнению с ними обычно то, что висит на ISA, отзывается шустро. Прокси здесь вполне уместен.
Другое дело, что прибивать его сразу и ко гному, и к systemd было плохой идеей; но кто пишет, тому и решать -- правда, там и внутри вот такое нашлось:
/* To match the Pegatron accelerometer code(как если бы в мире встречались только пегатроны).
* (see pega_accel_poll() in asus-laptop.c)
* we invert both x, and y values */
accel_x = -accel_x;
accel_y = -accel_y;
С таким подходом и 3G модем и WiFi карточка - сенсор. GPS приёмник - тяжёлая в плане потребления электроэнергии зараза и её куда логичнее дёргать отдельно и гасить когда ненужна. Всякие сенсоры освещённости, акселерометры и гироскопы - фигня которая жрёт на уровне погрешности и поэтому её можно держать в фоне без проблем (ну или завести за время приблизительно равное нулю), в то время как держать включенный GPS - накладно по потреблению, а завести вхолодную - долго и мучительно.
> Доступ к геолокации, сканеру отпечатков пальцев, акселерометру есть?К акселерометру точно есть, только с полгода назад там была прибита гвоздями инверсия осей, которая на подручной железке оказалась явно излишней (разработчику сообщил).
Без D-BUS-то ну совершенно же никак этого невозможно было сделать.
Учитывая, что у них всё через D-Bus построено - добавлять какой-то другой механизм было бы крайне глупо.
Вместо того чтоб вылезать из тоннеля, продвинемся еще немного вглубь.
Логично.
С точки зрения существующе кодовой базы вполнелогично. Если затевать революцию - то не с этого а, например, с описания новой арзитектуры, базирующейся на чём-то другом.Я, честно говоря, не понимаю, в чём в данном случае проблема - именно для подобных задач D-Bus подходит отлично. Дискавери, подписки - всё, что нужно.
ИМХО лучше для подобных задач подходит sysfs - унифицирован для всех устройств, а не только для датчиков, ненужны библиотеки и уж тем более демоны и завязки за конкретные системы инициализации.
> лучше для подобных задач подходит sysfsкак событие поставить на изменение значения? через неработающий с sysfs inotify или через опрос каждые 20-100мс, который будет разряжать батарейку?
Если программок будет 20 штук на датчик, каждая будет постоянно ломиться в этот sysfs файл?
>> лучше для подобных задач подходит sysfs
> как событие поставить на изменение значения? через неработающий с sysfs inotify или
> через опрос каждые 20-100мс, который будет разряжать батарейку?
> Если программок будет 20 штук на датчик, каждая будет постоянно ломиться в
> этот sysfs файл?А как conky работает? Как предлагаемый iio-sensor датчики опрашивает?
ИМХО если датчик сугубо информативный - опрашивать его чаще чем 1 раз в секунду нет смысла. Если датчик управляющий - то его в любом случаее придется опрашивать с определенной частотой иначе он просто зафлудит евентами.
Не вникал как у sysfs отслеживаются события от драйвера, но что-то там было. В любом случае лучше доработать sysfs, чем плодить новые прослойки завязанные не пойми за что.
> А как conky работает?Возьми strace да посмотри. Он вполне может и поллить запросто. Когда его писали - на эффективность от работы от батарейки, как бы это вам сказать...
> Как предлагаемый iio-sensor датчики опрашивает?
Вполне вероятно что поллингом.
> В любом случае лучше доработать sysfs, чем плодить новые прослойки
> завязанные не пойми за что.В N900 вон через d-bus рулятся почти все аспекты управления телефоном. Можно скажем system-wide запросить "самолетный режим". Даже из скрипта. Или программы. Удобно, что бы там мамонты не вякали.
А на обычном писюке сказать "а ну все радио заткнулись" как-то так по простому в общем то и нельзя в результате. Во зашибись, зато без d-bus.
>> А как conky работает?
> Возьми strace да посмотри. Он вполне может и поллить запросто. Когда его
> писали - на эффективность от работы от батарейки, как бы это
> вам сказать...Скорее наоборот - conky опрашивает датчики с заданным интервалом (устанавливается пользователем). Большинство датчиков не активны, пока не будет к ним обращения. Поэтому для них и не работает inotify.
Получается, что conky будет опрашивать все необходимые датчики раз в секунду. А iio-sensоrs будет опрашивать датчики и генерировать события гораздо чаще - 10-100 раз в секунду, ведь он не знает как часто они нужны приложению. Опять же, скорее всего iio-sensоrs будет отсылать одним сообщением все параметры датчика, даже если они не нужны для конкретного приложения.
Я давал ссылку на лор - там все эти аспекты обсудили.
> Можно скажем system-wide запросить "самолетный режим". Даже из скрипта. Или программы.
Какие гарантии, что все приложения обработают это сообщение корректно и действительно перестанут использовать радио связь? Должно быть не только удобно, но и надежно. ИМХО единственный надежный вариант - запрет связи на уровне драйвера, да и то если это не usb-wifi (со своей ОС) который может сам начать проверять обновления.
Никто не мешает - в качестве одной из ракций - какому-то компоненту погасить связь через драйвер, если оно действительно нужно. Но при этом все приложения будут знать, что мы ушли в режим полёта и на связь можно не рассчитывать. И вести себя соответственно.
> Никто не мешает - в качестве одной из ракций - какому-то компоненту
> погасить связь через драйвер, если оно действительно нужно.Какому именно? Если устройств связи несколько, как он определит какие гасить?
> Но при этом
> все приложения будут знать, что мы ушли в режим полёта и
> на связь можно не рассчитывать. И вести себя соответственно.Сейчас, как ни странно, при отключении сетевого кабеля все приложения использующие сеть тоже узнают, что ее нет (при попытке к ней обратиться).
Ну вот то что решало - какое устройство поднимать, то и опусти. Или ещё как - вопрос полиси, которая шине ортогональна.А принцип "ткнёмся - тогда и узнаем" - это и есть проблема, о которой я говорю. Влезли в своп - узнаем по тормозам. Отпала сеть - узнаем по ошибкам. Диск умирает - давайте его добьём торрентами. Место заканчивается на устройстве - нет, мы дисковый кэш свой ограничивать не будем - пусть всё дотупит до 0 байт, тогда узнаем. И так далее. Мне кажется, вменяемое взаимодействие софта между собой - гораздо лучшая идея.
> Ну вот то что решало - какое устройство поднимать, то и опусти.Так так сейчас и есть - скрипт или мега автоконфигуратор сети. То есть логичнее и оставить за ним эту работу, а не посылать ему события.
> А принцип "ткнёмся - тогда и узнаем" - это и есть проблема, о которой я говорю.
Это не проблема. Это проверка на ошибки.
> Влезли в своп - узнаем по тормозам.
Сейчас приложение не может узнать сколько памяти реально осталось?
> Отпала сеть - узнаем по ошибкам.
Вы предлагаете не проверять ошибки сети (обрыв провода, зависание сервера, etc)?
Если нет, то что даст дополнительное уведомление?> Диск умирает - давайте его добьём торрентами.
Зачем посылать в такой ситуации сообщения приложениям? Достаточно уведомить админа/пользователя и перевести проблемные диски в ro или вообще их отключить.
> Место заканчивается на устройстве - нет, мы дисковый кэш
> свой ограничивать не будем - пусть всё дотупит до 0 байт,
> тогда узнаем.Для этого существуют дисковые квоты.
> И так далее. Мне кажется, вменяемое взаимодействие софта между
> собой - гораздо лучшая идея.Возможно. Но вопрос в том, где и что и как реально должно взаимодействовать. Есть pipe, fifo, сигналы (kill -s). Да d-bus имеет больше возможностей, но в ущерб скорости, да и в реальной практике редко когда эти возможности нужны, а там где реально востребованы (audio) есть более специализированные решения с учетом всей специфики (jack).
Проверка на ошибки, да. А дать механизм, который бы ошибку предупредил - религия не позволяет?Я предлагаю оставить проверку ошибок в покое, а при возможности - уведомлять приложения о различных событиях/изменениях состояния как можно раньше. Чтобы (по крайней мере в штатном случае) не молча обрывалось соединение в самый неподходящий момент, когда приложение будет ждать ответ на DNS-запрос пол-минуты (и, соответственно, крутить индикатор ожидания пользователю). В ряде случаев это не поможет - но в большинстве ситуаций - улучшит user experience.
Нет, если на диске вырос relocation, или ещэ как SMART ругнулся - это не повод паниковать и уходить в readonly и нарушать какие-то важные активности пользорвателя. Но это вполне себе повод: 1) уведомить пользователя, что диск не особо надёжен 2) до его решения ограничить незначимый но интенсивный I/O. И уж точно принятие решения, что надо ограничивать и какие меры принимать - дело отнюдь не ядра, а либо самого приложения, этот I/O осуществляющего, либо работчего окружения, держащего общую конфигурацию.
С дисковыми квотами результат тот же - какой смысл загонять приложение в нештутную (даже если и обрабатываемую) ситуацию? Сидит, значит, пользователь, обрабатывает здоровенный графиечский файл - и вдруг выясняет, что сохранить он его не может - не важно, места нет или приложение/пользователя квотами обрезали. А А обработать прозрачно - религия не велит? Чтобы, допустим, рядом сидящий браузер кэш от недавно просмотренных видео почистил?
И, соответственно, речь не об audio, а обо всём спектре событий - от информации от железа до соообщений, отосланных из пользовательского скрипта.
> Проверка на ошибки, да. А дать механизм, который бы ошибку предупредил -
> религия не позволяет?Пока не вижу ситуаций, где это действительно былобы оправдано.
> Я предлагаю оставить проверку ошибок в покое, а при возможности - уведомлять
> приложения о различных событиях/изменениях состояния как можно раньше. Чтобы (по крайней
> мере в штатном случае) не молча обрывалось соединение в самый неподходящий
> момент,Потеря пакетов или сигнала (3g/wifi) вполне обычная ситуация и должна быть обработана корректно.
> когда приложение будет ждать ответ на DNS-запрос пол-минуты (и, соответственно,
> крутить индикатор ожидания пользователю). В ряде случаев это не поможет -
> но в большинстве ситуаций - улучшит user experience.Ждать оно будет только в одном случае - пока есть хоть какая-то надежда получить данные. Если сеть погашена, то реакция будет мгновенной. Погасите интерфейс с гейтом и попробуйте открыть что-нибудь в браузере.
> Нет, если на диске вырос relocation, или ещэ как SMART ругнулся -
> это не повод паниковать и уходить в readonly и нарушать какие-то
> важные активности пользорвателя. Но это вполне себе повод: 1) уведомить пользователя,
> что диск не особо надёженКонкретную реакцию должен определять администратор.
> 2) до его решения ограничить незначимый
> но интенсивный I/O. И уж точно принятие решения, что надо ограничивать
> и какие меры принимать - дело отнюдь не ядра, а либо
> самого приложения, этот I/O осуществляющего, либо работчего окружения, держащего общую
> конфигурацию.Такой подход не приемлем. Мы получим либо тормоза, либо продолжение активного i/o. Приложения сами по себе ничего не должны решать. Должна быть задана конкретная реакция на конкретную проблему. Оставлять такие вещи на усмотрение программ и наедятся что авторы были не дураки и все продумали как минимум наивно. Всегда найдется та программа, которая проигнорирует подобное сообщение.
> С дисковыми квотами результат тот же - какой смысл загонять приложение в
> нештутную (даже если и обрабатываемую) ситуацию? Сидит, значит, пользователь, обрабатывает
> здоровенный графиечский файл - и вдруг выясняет, что сохранить он его
> не может - не важно, места нет или приложение/пользователя квотами обрезали.По-вашему сейчас приложение не может проверить/зарезервировать свободное место, до начал операции? Насколько я помню тот же transmission заранее предупреждает, если на разделе заканчивается место.
> А А обработать прозрачно - религия не велит? Чтобы, допустим, рядом
> сидящий браузер кэш от недавно просмотренных видео почистил?1. Если я задаю размер кэша вручную, значит я хочу что бы его размер таким и был, вне зависимости хватает остальным места или нет.
2. Если размер кэша стоит авто, то браузер должен при малейшем намеке на нехватку места урезать кэш. Насколько я знаю, так сейчас и происходит.ИМХО вполне нормальная практика просто оповестить пользователя, о том что место заканчивается. А уж что лучше удалить он решит сам. А то получится, что пользователь смотрел online фильм и копировал тучу фильмов на съемный диск. Но лажанулся и отправил не на тот диск. Сперва у него начал дергаться фильм, так как удалился из кэша, а затем все равно кончилось место.
> И, соответственно, речь не об audio, а обо всём спектре событий -
> от информации от железа до соообщений, отосланных из пользовательского скрипта.Я не отрицаю, что где-то это может быть полезно. Но призываю лишний раз подумать, а надо ли оно в конкретной ситуации.
> Скорее наоборот - conky опрашивает датчики с заданным интерваломВНЕЗАПНО, именно это и называется polling :D
> Большинство датчиков не активны, пока не будет к ним обращения.
Вот это совсем не факт. За все датчики расписываться как-то сильно шустро, не?
> Поэтому для них и не работает inotify.
А с практической точки зрения - надо постоянно клевать датчик из программы, пробуждая программу и тыкаясь в датчик.
Самое очевидное: free fall detector например явно работает всегда. А вот его состояние поллингом проверять - нерезультативно. Если вы будете его раз в секунду проверять, ноут за эту секунду успеет приложиться уже. С работаюшим хардом. Царапнув поверхность диска. А если его дергать часто - программа не даст процу в low power режим уйти скорее всего.
И да, а коньки как-то обрабатывают переход системы на батарею? Ну там скажем от адаптера - можно большинство датчиков 10 раз в секунду сканить, а от батареи - лучше раз в пару секунд. В то что гном с профайлами питания и d-bus так сможет - я еще поверю.
> 10-100 раз в секунду, ведь он не знает как часто они нужны приложению.
О, это идея! Внедрить kdbus в ядро и пусть ядро сразу и рассылает по kdbus, сразу по факту доступности инфы от железки :).
> Опять же, скорее всего iio-sensоrs будет отсылать одним сообщением
> все параметры датчика, даже если они не нужны для конкретного приложения.Проблема скорее в том что проц не уходит на пониженные частоты/в глубокие режимы сна если кто-то дергается. И когда это хренадцать программ, читающих датчики всех мастей - получаеся "не очень".
Грубо говоря, если 5 программ надо температуру проца, в обычном случае все 5 будут дергать датчик. А так один демон дернет датчие и раскидает всем 5 заинтересованным, по мере необходимости, что по идее эффективнее.
> Я давал ссылку на лор - там все эти аспекты обсудили.
Я не посещаю LOR, увы. Посылать меня туда бесполезно.
> Какие гарантии, что все приложения обработают это сообщение корректно
Так же как и со всеми остальными программами. За системные - отвечают QA которые тестировали релиз. Апликухи которые поставил юзерь ... для них это в общем случае скорее информативный сигнал. Ну то-есть они могут скажем корректно свернуть сетевую активность, если хотят, зная что сейчас сеть пропадет. А не хотят - активность зарубится как получится. Когда системный компонент пойдет и потушит сетевой интерфейс.
Зато все это рулится одной кнопой из гуя - offline mode. Или скриптом - одно сообщение по dbus. Удобно. Одно логически сгруппированное действо - одним действием с системой, с минимальным шансом сделать что-то не так. И минимально необходимыми знаниями - "хочу самолетный режим". Программе или скрипту "кнопочка самолетного режима" нафиг не упало знать скажем полный список сетевых и-фейсов и как их правильно потушить. D-bus это обеспечивает.
> и действительно перестанут использовать радио связь?
Это будет чуть иначе: системные компоненты потенциально заинтересованные в сообщении подпишутся на него заранее. А получив его - пойдут да вырубят радио на "своих" железках. Отправителю сообщения вообще не надо знать кто и как это будет делать, ему надо только запросить самолетный режим. Остальное не его сложности. Элементарное разделение труда.
Обычные программы ... могут принять к сведению сообщение и что-то сделать, понимая что системные компоненты сейчас уберут сеть. А могут ничего не делать - тогда их просто обуют на сеть неожиданно для них. "Продолжить использовать" интерфейс который системные компоненты форсанули down - у программ не получится по причинческим технинам :P.
Ну то-есть зайдя как рут - можно это переиграть, ессно. Чудес не бывает: рут может всё. Но обычные юзермодовые программы в общем случае просто обломаются. Или ожидаемо для себя, если они подписались на сообщение, или ВНЕЗАПНО, если не подписались.
> Должно быть не только удобно, но и надежно.
В общем случае обычные юзермодовые программы ничего не могут сделать по поводу того что системные компоненты с повышенными привилегиями пришли и выключили по сообщению интерфейсы. Рут конечно и в африке рут, но защищаться от рута никто и не собирался.
И да, вы можете предложить решение лучше? Чтобы было столь же просто для инициатора?
Я вот могу: засунуть kdbus в ядро, ядро - самый ядреный компонент системы, который пишется надежными людьми :). Получив сообщение - ядро само вырубит беспроводные ифейсы. Уж у него полномочий на всех хватит, а если вы не доверяете надежности ядра - то про остальное речь вообще не идет :P.
> ИМХО единственный надежный вариант - запрет связи на уровне драйвера,
Ну то-есть вы хотите сказать нам что kdbus очень нужен и полезен? :)
> и то если это не usb-wifi (со своей ОС) который может
> сам начать проверять обновления.Большинство usb-свистков таки относительно простые штуки. А то что вы имеете в виду - это извините мобильные роутеры и прочие, а не свистки. Самостоятельные (!!!!) компьютеры. Это такой намек что d-bus надо еще сетевое межсистемное конективити по хорошему, чтобы и такие штуки были в курсе что им надо заткнуться? :) А еще в идеале неплохо бы после предупреждения снять питание с девайса. На всякий. И питание экономится, и что-то там обновлять девайс в общем случае не сможет :)
>> Большинство датчиков не активны, пока не будет к ним обращения.
> Вот это совсем не факт. За все датчики расписываться как-то сильно шустро,
> не?Еще раз "Поэтому для них и не работает inotify.", для тех что обновляются сами можно получить событие через inotify.
>> Поэтому для них и не работает inotify.
> А с практической точки зрения - надо постоянно клевать датчик из программы,
> пробуждая программу и тыкаясь в датчик.
> Самое очевидное: free fall detector например явно работает всегда.Значит и inotify для него работает.
> И да, а коньки как-то обрабатывают переход системы на батарею? Ну там
> скажем от адаптера - можно большинство датчиков 10 раз в секунду
> сканить, а от батареи - лучше раз в пару секунд.Все зависит от вашей фантазии - вплоть до перехода на другой конфиг с отключением лишних показаний.
> Проблема скорее в том что проц не уходит на пониженные частоты/в глубокие
> режимы сна если кто-то дергается. И когда это хренадцать программ, читающих
> датчики всех мастей - получаеся "не очень".
> Грубо говоря, если 5 программ надо температуру проца, в обычном случае все
> 5 будут дергать датчик. А так один демон дернет датчие и
> раскидает всем 5 заинтересованным, по мере необходимости, что по идее эффективнее.А если запущен только один conky и читает он датчики очень выборочно и не все параметры?
Сколько при этом раз демон дернет датчик за секунду? Пять программ могут дергать раз в секунду и только нужные параметры конкретных датчиков. Демону же придется рассчитывать на худшее и дергать 10-100 раз в секунду и все параметры.
>[оверквотинг удален]
> Так же как и со всеми остальными программами. За системные - отвечают
> QA которые тестировали релиз. Апликухи которые поставил юзерь ... для них
> это в общем случае скорее информативный сигнал. Ну то-есть они могут
> скажем корректно свернуть сетевую активность, если хотят, зная что сейчас сеть
> пропадет. А не хотят - активность зарубится как получится. Когда системный
> компонент пойдет и потушит сетевой интерфейс.
> Зато все это рулится одной кнопой из гуя - offline mode. Или
> скриптом - одно сообщение по dbus. Удобно. Одно логически сгруппированное действо
> - одним действием с системой, с минимальным шансом сделать что-то не
> так. И минимально необходимыми знаниями - "хочу самолетный режим".Ну а сеть чем вы настраиваете? Логичнее поместить этот режим как один из профилей настройки сети.
> Программе или
> скрипту "кнопочка самолетного режима" нафиг не упало знать скажем полный список
> сетевых и-фейсов и как их правильно потушить. D-bus это обеспечивает.
>> и действительно перестанут использовать радио связь?
> Это будет чуть иначе: системные компоненты потенциально заинтересованные в сообщении подпишутся
> на него заранее. А получив его - пойдут да вырубят радио
> на "своих" железках. Отправителю сообщения вообще не надо знать кто и
> как это будет делать, ему надо только запросить самолетный режим. Остальное
> не его сложности. Элементарное разделение труда.Вот именно - это должно быть в сетевом конфигураторе. А не в каждом сетевом приложении.
> И да, вы можете предложить решение лучше? Чтобы было столь же просто
> для инициатора?Инициатор - пользователь? Кнопку в конфигураторе или опцию если конфигуратор консольный. И можно обойтись без сообщений, их обработки и демонов.
>> ИМХО единственный надежный вариант - запрет связи на уровне драйвера,
> Ну то-есть вы хотите сказать нам что kdbus очень нужен и полезен?
> :)У программы под рутом и так хватит привилегий для этого.
>> и то если это не usb-wifi (со своей ОС) который может
>> сам начать проверять обновления.
> Большинство usb-свистков таки относительно простые штуки. А то что вы имеете в
> виду - это извините мобильные роутеры и прочие, а не свистки.ХЗ все виданные мной huawei за последние лет пять именно такие. Даже если прикидываются обычным ppp.
> Самостоятельные (!!!!) компьютеры. Это такой намек что d-bus надо еще сетевое
> межсистемное конективити по хорошему, чтобы и такие штуки были в курсе
> что им надо заткнуться? :)Не поможет :) Всегда найдется тот, кто прикинется что ничего не знает и знать не желает.
> А еще в идеале неплохо бы
> после предупреждения снять питание с девайса. На всякий. И питание экономится,
> и что-то там обновлять девайс в общем случае не сможет :)Вот это верно, давно нужно унифицировать возможность отключать отдельные usb порты.
> Еще раз "Поэтому для них и не работает inotify.", для тех
> что обновляются сами можно получить событие через inotify.А откуда такие сведения взяты? И для начала: а что вами подразумевается под "активностью датчика"?
Я вижу тут как минимум 2 разные сущности:
- Датчик где-то там внутри себя что-то делает (e.g. производит замеры).
- Датчик принимает участие в той или иной активности на шине (e.g. отгружает эти замеры хосту).Это 2 разные вещи и как они связаны в конкретном случае - весьма зависит от.
> Значит и inotify для него работает.
Хз, я бы это за данность не считал без проверки.
Если что - я достаточно активно интересовался как это работает и имею заметить что сделать энумерацию доступных показометров энного типа через sysfs - то еще приключение. Обход большой иерархии с кучей симлинков, половина которых имеют свойство указывать друг на друга - те еще грабли. А еще и на inotify там потом подписываться... выглядит как куча головняка на ровном месте. На мой взгляд, такой интерфейс к показометрам - не предел мечтаний для апликушников, мягко говоря.
> Все зависит от вашей фантазии - вплоть до перехода на другой конфиг
> с отключением лишних показаний.Знаете, теоретически я себе и операционку целиком мог бы написать, ограничиваясь только моей фантазией. А практически - я не горю желанием изобретать велики из чугуниевых труб, обнаруживая потом что нормальные люди из алюминия и карбона делают их в 20 раз лучше и с меньшими мучениями. Поэтому если кто хочет запилить более-менее простой в использовании и общеупотребительный интерфейс - я только за.
А чего такого в том чтобы sysfs остался low-level уровнем, а эта штука через dbus - более high-level, где можно как-то по простому запросить у системы нечто типа "а какие градусники есть и что показывают?"
> А если запущен только один conky и читает он датчики очень выборочно
> и не все параметры?Ну я бы на месте упомянутой штуки тоже читал только датчики, на инфо от которых кто-то подписался.
> же придется рассчитывать на худшее и дергать 10-100 раз в секунду
> и все параметры.По хорошему - программы могли бы при подписке указывать свой аппетит aka требования к тому как они это хотели бы. А в ответ можно было бы еще и по хорошему сообщить что по факту светит с учетом умений железа и софта. Ну и с учетом аппетитов потребителей показаний дергать. А сейчас в sysfs btw вообще IIRC для датчиков нет никаких данных о скорости с которой датчики могут поставлять инфо, о разрешении и прочем. Подобные данные сейчас можно вообще получить только или экспериментально или после чтения на даташита и/или кода драйвера. Догадайся сам, дорогой апликушник, что этот датчик может. Удобно :)
> Ну а сеть чем вы настраиваете? Логичнее поместить этот режим как один
> из профилей настройки сети.Как вариант - почему бы и нет? Ну и выставлять сие по свистку от D-bus со стороны того кто эти профили применяет. Да, вы знаете, программа которая просит самолетный режим - совершенно не обязана быть моим менеджером сети! Виджет с кнопочкой или там какой-то обработчик нажатия аппаратной кнопки - совсем не обязан быть менеджером сети или что-то там знать о том какие у меня профайлы, настройки и-фейсов, список этих и-фейсов и прочая.
Есть желание: "не излучать в эфир". Когда юзер нажал вот эту кнопку. В контексте этого желания знания о том что там является сетевым менеджером, какие у него вообше есть профили, сколько и каких и-фейсов и прочая - элементарно лишние. Логичнее всего если обработчик кнопки запулит сообщение в шину, а остальные кому это интересно пусть уже разбираются как это обеспечить. Нормальное иерархическое построение абстракций, с откидыванием явно лишних знаний и действий там где это даром не упало.
> Вот именно - это должно быть в сетевом конфигураторе. А не в
> каждом сетевом приложении.Нет, вот извините. Сетевой конфигуратор не должен быть всеми мыслимыми вариантами виджетов. И все мыслимые комбо аппаратных кнопок он обрабатывать он не должен. Он - конфигуратор сети, а не куча виджетов. И не мега-обработчик кнопок. Этим пусть занимается кто-нибудь другой. А вот потом этот другой по логике вещей должен пульнуть сообщение в шину. А сетевой конфигуратор и прочие причастные пусть там уже дальше разбираются, получив его.
> Инициатор - пользователь? Кнопку в конфигураторе или опцию если конфигуратор консольный.
Простите, а с фуя ли сетевой бэкэнд должен заниматься юзеринтерфейсом с пользователями? И почему мне не должно быть можно порулить как из гуя так и из консоли? А то и с хардварной кнопки какой-нибудь, или их комбо.
В этом плане тот же NM например вполне себе разнесен на бэкэнд (собссно network-manager), а консольный клиент и гуйные клиенты разных DE к этому интерфейсятся. И d-bus оно использует. Нокия просто это сделала легеньким, хорошо работающим и доведенным до ума. Так что юзеру не приходится вбивать 20 костылей и подпорок.
> И можно обойтись без сообщений, их обработки и демонов.
Да в принципе можно и без компьютеров обойтись. Считать на счетах и в тетрадках. Но вот боюсь я не хочу чтобы сетевой конфигуратор был единственным UI к себе, напрочь лишенным возможности взаимодействия с остальным софтом.
> У программы под рутом и так хватит привилегий для этого.
У программ под рутом хватит прав чтобы записать нули в /dev/sda, или что там у вас :). Поэтому под рутом пускаются только сильно некоторые программы, по сильно некоторым случаям.
> ХЗ все виданные мной huawei за последние лет пять именно такие. Даже
> если прикидываются обычным ppp.А, если вы про 3G свисток, внутри любого сотового девайса есть как минимум неслабая фирмварь с протокольным стеком и каким-то юзеринтерфейсом к нему. Этот стек - большой и сложный и фирмварь весит минимум несколько мегабайтов, вполне себе будучи чем-то типа RTOS. И процов там может быть несколько. Как минимум - их там обычно два: "управляюший", с которым вы общаетесь, и "сигнальный", который делает heavy lifting. А иногда процов и больше - скажем для юзеринтерфейса бывает отдельный проц. Если к нему экран прицепить, выходит смартфон.
Вайфая это в основном не касается. Ну то-есть там чаще всего лишь небольшой сервисный процик, который сугубо гоняет данные из usb в радио и операционкой сие называть больно жирно. Свежий пример - ath9k_htc и фирмварь, недавно открытая квалкоммом на 9271 и 7010.
С сотовыми сетями все сложнее: там очень кастомный протокол, подразумевающий дофига сервисных операций всех мастей. А если юзер хочет линух пускать - его на отдельный проц только пускают, дать доступ на проц который протокольный стек крутит все сцут и не то чтобы без причин - все это многомегабайтное глюкало очень даже может околеть от тыкания палочкой, в хучшем случае с завалом неслабого куска сети :)
> Всегда найдется тот, кто прикинется что ничего не знает и знать не желает.
Ну тогда получит ВНЕЗАПНЫЙ power gating или сброс. Если его угораздило что-то обновлять, производитель получит не менее ВНЕЗАПНЫЙ возврат по гарантии от обозленного юзверя.
> Вот это верно, давно нужно унифицировать возможность отключать отдельные usb порты.
Да это вроде в стандарте даже заложено. И да, позвольте все-таки не рассматривать откровенно бажные, а то и просто malicious железки: в таких допущениях вы вообще не можете надеяться на сколь-нибудь корректную работу системы. А так вон наиболее прошаренные люди делают сотовому модулю power gating отдельным полевиком, через GPIO системного проца. Как в NEO900. Снятие питания - оспорить можно только в спортлото. Тут даже бажная и вредная железка обломится.
>> Еще раз "Поэтому для них и не работает inotify.", для тех
>> что обновляются сами можно получить событие через inotify.
> А откуда такие сведения взяты?Из гугла по "sysfs inotify".
> И для начала: а что вами подразумевается
> под "активностью датчика"?
> Я вижу тут как минимум 2 разные сущности:
> - Датчик где-то там внутри себя что-то делает (e.g. производит замеры).
> - Датчик принимает участие в той или иной активности на шине (e.g.
> отгружает эти замеры хосту).
> Это 2 разные вещи и как они связаны в конкретном случае -
> весьма зависит от.С точки зрения sysfs, датчики делятся на две категории:
1. Драйвер, по мере поступления новых данных, уведомляет sysfs. Соответственно inotify для в таком случае работает.
2. Драйвер ничего не делает, пока не получит запрос. Inotify в таком случае не работает естественно. Хотя возможен следующий вариант: программы следят за таким датчиком через inotify, одной из них надоедает ждать и она делает запрос. а ответ в этом случае получат все. Частота запросов будет определяться самой нетерпеливой программой.>> Значит и inotify для него работает.
> Хз, я бы это за данность не считал без проверки.
> Если что - я достаточно активно интересовался как это работает и имею
> заметить что сделать энумерацию доступных показометров энного типа через sysfs -
> то еще приключение. Обход большой иерархии с кучей симлинков, половина которых
> имеют свойство указывать друг на друга - те еще грабли. А
> еще и на inotify там потом подписываться... выглядит как куча головняка
> на ровном месте. На мой взгляд, такой интерфейс к показометрам -
> не предел мечтаний для апликушников, мягко говоря.Согласен, sysfs далек от совершенства. Но его нужно улучшать, а не пытаться прятать его проблемы.
> А чего такого в том чтобы sysfs остался low-level уровнем, а эта
> штука через dbus - более high-level, где можно как-то по простому
> запросить у системы нечто типа "а какие градусники есть и что
> показывают?"Как она определит что градусник, а что нет? Выше человек еще упоминал fan и pwm, а они очень разные бывают.
>> же придется рассчитывать на худшее и дергать 10-100 раз в секунду
>> и все параметры.
> По хорошему - программы могли бы при подписке указывать свой аппетит aka
> требования к тому как они это хотели бы. А в ответ
> можно было бы еще и по хорошему сообщить что по факту
> светит с учетом умений железа и софта. Ну и с учетом
> аппетитов потребителей показаний дергать.И станет еще сложнее - а нужно было всего-то один раз консольное программе температуру глянуть.
> А сейчас в sysfs btw вообще IIRC
> для датчиков нет никаких данных о скорости с которой датчики могут
> поставлять инфо, о разрешении и прочем. Подобные данные сейчас можно вообще
> получить только или экспериментально или после чтения на даташита и/или кода
> драйвера. Догадайся сам, дорогой апликушник, что этот датчик может. Удобно :)По тому, что в большинстве случаев скорость опроса ограничивается здравым смыслом или драйвером - если драйвер знает, что чаще чем 10 раз в секунду опрашивать данный датчик бессмысленно, то драйвер просто будет отдавать последнее значение, пока оно не устареет.
>> Ну а сеть чем вы настраиваете? Логичнее поместить этот режим как один
>> из профилей настройки сети.
> Как вариант - почему бы и нет? Ну и выставлять сие по
> свистку от D-bus со стороны того кто эти профили применяет. Да,
> вы знаете, программа которая просит самолетный режим - совершенно не обязана
> быть моим менеджером сети! Виджет с кнопочкой или там какой-то обработчик
> нажатия аппаратной кнопки - совсем не обязан быть менеджером сети или
> что-то там знать о том какие у меня профайлы, настройки и-фейсов,
> список этих и-фейсов и прочая.Я понял вашу позицию. Не нравится мне в ней то, что поверх конфигуратора сети появляется еще один конфигуратор (виджет). Нужно вводить дополнительный согласованный формат/протокол между этими конфигураторами. Геморроя много, а смысла мало.
> Есть желание: "не излучать в эфир". Когда юзер нажал вот эту кнопку.
> В контексте этого желания знания о том что там является сетевым
> менеджером, какие у него вообше есть профили, сколько и каких и-фейсов
> и прочая - элементарно лишние. Логичнее всего если обработчик кнопки запулит
> сообщение в шину, а остальные кому это интересно пусть уже разбираются
> как это обеспечить. Нормальное иерархическое построение абстракций, с откидыванием явно
> лишних знаний и действий там где это даром не упало.И что это реально дает? Возможность навоять свою кнопку, как в андройде? Ради одной кнопки весь этот огород? Есть варианты попроще.
>> Вот именно - это должно быть в сетевом конфигураторе. А не в
>> каждом сетевом приложении.
> Нет, вот извините. Сетевой конфигуратор не должен быть всеми мыслимыми вариантами виджетов.
> И все мыслимые комбо аппаратных кнопок он обрабатывать он не должен.
> Он - конфигуратор сети, а не куча виджетов. И не мега-обработчик
> кнопок. Этим пусть занимается кто-нибудь другой. А вот потом этот другой
> по логике вещей должен пульнуть сообщение в шину. А сетевой конфигуратор
> и прочие причастные пусть там уже дальше разбираются, получив его.Да не нужно ничего некуда пулять - делим конфигуратор на frontend и backend. Frontend'ов может быть куча - от простых однокнопочных, до навороченных.
>> У программы под рутом и так хватит привилегий для этого.
> У программ под рутом хватит прав чтобы записать нули в /dev/sda, или
> что там у вас :). Поэтому под рутом пускаются только сильно
> некоторые программы, по сильно некоторым случаям.Не понял, а предложенный вами kdbus значит под guest'ом работает ? :)
>> Вот это верно, давно нужно унифицировать возможность отключать отдельные usb порты.
> Да это вроде в стандарте даже заложено.Как-то раз полдня убил - ничего не получилось :( Там в дебрях usb - хабы, в теории можно только весь хаб гасить, а не отдельные порты. Но у меня и этого не получилось.
> Из гугла по "sysfs inotify".Ну если вы такой джедай - может подскажете где посмотреть на не очень жуткий кусок кода обхода sysfs на си, где всякие грабли - обпрыганы? Ну вот допустим я хочу найти все градусники в системе. Желательно - поняв что это за градусники и например какие у них возможные диапазоны значений. Еще лучше если оно нормально обрабатывает все ошибки всех операций.
> для в таком случае работает.
...
> делает запрос. а ответ в этом случае получат все. Частота запросов
> будет определяться самой нетерпеливой программой.А, вот оно что. Так понятнее что вы имели в виду, спасибо.
//кстати еще спасибы за сватание мне udev, это кажется вы были. Я через него научился делать некоторые вещи относительно безграбельно и не очень криво.
> Согласен, sysfs далек от совершенства. Но его нужно улучшать, а не пытаться
> прятать его проблемы.Не имею ничего против улучшения sysfs. Заметьте, ни я, ни гномеры не предлагали его выпилить и заменить. Они как я понимаю предлагали прослойку для апликушников пишущих десктопные программы, которым не в кассу делать кучу (около)файловых операций, проверяя^W забивая на пару десятков потенциальных ошибок в самых разных местах.
> Как она определит что градусник, а что нет?
Градусник - это то что показывает температуру, очевидно. А вот как определить - было бы неплохо если бы гномеры сделали какие-то фильтры, или типа того, чтобы каждый первый апликушник не ломал над этим голову сам.
> Выше человек еще упоминал fan и pwm, а они очень разные бывают.
Во первых, они - не градусники. Во вторых, я немного поинтересовался вопросом, когда АМДшники запиливали управление вентилем. Ну и насколько я понял - некий "стандарт" поведения там устаканился. Сам по себе PWM вполне однозначно характеризуется коэффициентом заполнения. Тут правда возможны варианты кто его меняет: железка со своей стороны, софт со своей, и как это происходит. АМДшники по этому поводу там довесок вывесили, позволяющий как уповать на авторегулирование набортным сервисным процом (по дефолту) так и самому порулить. Сам по себе коэффициент заполнения - во всех PWMах более-менее однозначная штука и как он может быть сильно по разному - ну хз.
> И станет еще сложнее - а нужно было всего-то один раз консольное
> программе температуру глянуть.Где-то сложнее. Где-то проще. Апликушнику имхо было бы проще сделать полтора обращения к гномерской приблуде чем ...цать операций с ФС и файлами, каждая из которых потенциально может обломаться.
> датчик бессмысленно, то драйвер просто будет отдавать последнее
> значение, пока оно не устареет.И все бы замечательно. Вот только неплохо бы в принципе знать динамику и диапазоны датчика, а также что это вообще такое. Ну например чтобы понять с какой скоростью имеет смысл перерисовывать показометр. А то глупо перерисовывать 5 раз в секунду для датчика который оказывается обновляется не чаще чем 1 раз в секунду.
> Я понял вашу позицию. Не нравится мне в ней то, что поверх
> конфигуратора сети появляется еще один конфигуратор (виджет).А я считаю что плохо когда программы - вещь в себе и не могут взаимодействовать с другими программами. Одна из сильных сторон unix way - возможность собирать систему из кубиков, соединяя их между собой. Но как видим, практика показала что не все то что люди хотят от компьютеров сейчас хорошо делается как именно файловые операции.
Собственно какой-то зачаточный IPC был много лет. Просто он был сделан в виде в котором у него сравнительно мало применений. Ну как у отсылки RAW фреймов эзернета применений здорово меньше чем скажем программ уповающих на работу с HTTP. Имхо было бы неплохо взаимодействие между программами неплохо бы расширить еще и шиной. Модель pub/sub имеет свои плюсы, а некоторые вещи так выглядят наиболее логично и позволяют стыковку самых разных программ по самым разным поводам. В несколько более структурированном виде чем остальные варианты.
> Нужно вводить дополнительный согласованный формат/протокол между этими
> конфигураторами. Геморроя много,В случае шины это как раз получается относительно логично и относительно просто. Пример N900 тому подтверждением.
> а смысла мало.
Не согласен. Возможность воздействовать между программами, делая те или иные действия из той программы удобна мне - это хорошо и правильно. А вот прибивать все гвоздями к 1-2 программам - гм, ну мы вроде не в винде, чтобы столь глупые ограничения на использование системы вводить.
> И что это реально дает? Возможность навоять свою кнопку, как в андройде?
> Ради одной кнопки весь этот огород?В локально этом примере - да, это дает мне возможность нажать именно ту кнопку именно так как мне будет удобно. Без залета апликушника на выписывание полновесной морды к сетевому бэкэнду.
В более глобальном масштабе это дает возможность взаимодействия между программами aka IPC в структурированном формате. Когда можно попросить кого-то сделать что-то в каком-то структурированном виде, так что это даже еще и сможет работать между несколькими разными программами.
> Есть варианты попроще.
Например?
> Да не нужно ничего некуда пулять - делим конфигуратор на frontend и
> backend. Frontend'ов может быть куча - от простых однокнопочных, до навороченных.А как насчет возможности использовать и полноценный конфигуратор для настройки сети в разных позах, но при этом получив и удобную кнопку для того чтобы быстро заткнуть wireless? Копаться в навороченном конфигураторе для срубания wireless - очень так себе идея. Получается что нужен некий co-existence минимум 2 разных программ воздействующих на бэкэнд. А это опять же какой-то арбитраж, информирование всех причастных что конфигурация изменилась, чтобы они не глючили в поведении и отображении статусов. Ну то-есть начинается переизобретение шины...
> Не понял, а предложенный вами kdbus значит под guest'ом работает ? :)
А kdbus как таковой - самая низкоуровневая часть шины. Он сетевые интерфейсы сам по себе не дергает by design. И в /dev/sda нули не пишет. Он сообщения между программами гоняет. Само по себе это "относительно безвредная активность". Единственное что возможно, пользуясь случаем, стоило бы устроить некий редизайн dbus, раз уж есть мысль в кернел "увековечить".
> не отдельные порты. Но у меня и этого не получилось.
Сколько я себя помню - с этим всегда были какие-то непонятки. Стандарт вроде как прописывает это, но реально имеет свойство не работать. В ряде железяк вроде как Vbus просто прицеплен на +5V, спасибо если через предохранитель. Ну и отключить оно это не сможет ну хоть там что. Вообще, в usb довольно много костылей и бестолковостей, вплоть до состояния когда все начинают забивать на стандарт "потому что так удобнее". Характерный пример - удлинители USB. Стандарт вроде запрещает, но всем вроде как пофиг. Или usb-otg, который часто делается через жо...хм, обычный micro-B порт вместо эзотеричного micro-A, который никто в глаза не видел. Хоть host через micro-B вроде как и не по спекам, но кабели micro-B -> AF как бы есть.
> где посмотреть на не очень жуткий кусок кода обхода sysfs на си, где всякие грабли
> - обпрыганы? Ну вот допустим я хочу найти все градусники в системе.Возможно, пригодятся sysfsutils и libsysfs (отталкивался бы от systool -c, наверное).
> //кстати еще спасибы за сватание мне udev, это кажется вы были. Я
> через него научился делать некоторые вещи относительно безграбельно и не очень
> криво.Всегда пожалуйста, для меня эти беседы тоже о многом заставили задуматься ;)
> Не имею ничего против улучшения sysfs. Заметьте, ни я, ни гномеры не
> предлагали его выпилить и заменить. Они как я понимаю предлагали прослойку
> для апликушников пишущих десктопные программы, которым не в кассу делать кучу
> (около)файловых операций, проверяя^W забивая на пару десятков потенциальных ошибок в самых
> разных местах.Дело не в том, sysfs конечно никто не выкинет. Но мне не нравится, когда вместо исправления делают новый проект поверх старого. Нужно исправлять проблемы, а не прятать их за прослойками.
>> Как она определит что градусник, а что нет?
> Градусник - это то что показывает температуру, очевидно. А вот как определить
> - было бы неплохо если бы гномеры сделали какие-то фильтры, или
> типа того, чтобы каждый первый апликушник не ломал над этим голову
> сам.Это понятно, но как сами гномеры узнают, что есть что? Я к тому, что если это делать по нормальному, все равно придется править sysfs и драйвера. Иначе будет работать только на пяти датчиках (как в новости) до которых гномеры дотянулись и запихали в свою базу (завязанную за гном и systemd). Ведь все только выиграют, если исправить проблему на уровне ядра.
>> Выше человек еще упоминал fan и pwm, а они очень разные бывают.
> Во первых, они - не градусники. Во вторых, я немного поинтересовался вопросом,
> когда АМДшники запиливали управление вентилем. Ну и насколько я понял -
> некий "стандарт" поведения там устаканился. Сам по себе PWM вполне однозначно
> характеризуется коэффициентом заполнения.На первый взгляд - да, но глубже получается, что нет однозначной связи между заполнением и скоростью вентилятора. Более того pwm может иметь переключение базовой частоты.
>Тут правда возможны варианты кто его меняет:
> железка со своей стороны, софт со своей, и как это происходит.
> АМДшники по этому поводу там довесок вывесили, позволяющий как уповать на
> авторегулирование набортным сервисным процом (по дефолту) так и самому порулить. Сам
> по себе коэффициент заполнения - во всех PWMах более-менее однозначная штука
> и как он может быть сильно по разному - ну хз.Гляньте даташит на it87xx. У меня как раз пару дней назад дошли руки его нормально настроить. То, что вы назвали авторегулированием поддается настройке, притом весьма гибкой. Изначально я хотел повесить демона который бы управлял оборотами. Но не нравилось то, что в случае сбоя (зависание компьютера/kernel panic/etc) вентилятор станет не управляемым. Да и будет лишний раз дергать проц из спячки. Но глянув в даташит был приятно удивлен - гибко и надежно и без лишних демонов.
> И все бы замечательно. Вот только неплохо бы в принципе знать динамику
> и диапазоны датчика, а также что это вообще такое. Ну например
> чтобы понять с какой скоростью имеет смысл перерисовывать показометр. А то
> глупо перерисовывать 5 раз в секунду для датчика который оказывается обновляется
> не чаще чем 1 раз в секунду.Дело за драйвером - он вполне может показывать подобные сведения через sysfs как дополнительные свойства.
> А я считаю что плохо когда программы - вещь в себе и
> не могут взаимодействовать с другими программами. Одна из сильных сторон unix
> way - возможность собирать систему из кубиков, соединяя их между собой.
> Но как видим, практика показала что не все то что люди
> хотят от компьютеров сейчас хорошо делается как именно файловые операции.Полностью согласен. Но хочется, чтобы это было что-то действительно простое и гибкое, без overhead'а и многостраничный стандартов. Возможно kdbus и станет первым шагом.
> Собственно какой-то зачаточный IPC был много лет. Просто он был сделан в
> виде в котором у него сравнительно мало применений. Ну как у
> отсылки RAW фреймов эзернета применений здорово меньше чем скажем программ уповающих
> на работу с HTTP. Имхо было бы неплохо взаимодействие между программами
> неплохо бы расширить еще и шиной. Модель pub/sub имеет свои плюсы,
> а некоторые вещи так выглядят наиболее логично и позволяют стыковку самых
> разных программ по самым разным поводам. В несколько более структурированном виде
> чем остальные варианты.Верно, просто в наше время стыковка будет по поводу и без повода, будут рассылаться сотни/тысячи сообщение в секунду, а реально полезных будут единицы.
> Не согласен. Возможность воздействовать между программами, делая те или иные действия из
> той программы удобна мне - это хорошо и правильно. А вот
> прибивать все гвоздями к 1-2 программам - гм, ну мы вроде
> не в винде, чтобы столь глупые ограничения на использование системы вводить.Да, но пока эти "глупые ограничения" спасают от еще большей глупости использовать ipc для всего подряд и соединяться со всем подряд. В итоге будет как в вебе - лезешь на один сайт, а он грузит тонну мусора с других сайтов. И придется изобретать adblock для ipc ;)
> Я не посещаю LORКоллега :)
Элита в треде. Все в колхоз! ))
> Элита в треде. Все в колхоз! ))Не знаю, никакого элитизма в этом нет. Он мне просто не нравится. Начиная от того что я считаю домен третьего уровня позором для ресурса серьезнее домашней странички Васи Пупкина, и заканчивая тем что там #$%нутые на всю голову модераторы. Плюс неудобный форум, неудобные формы в этом форуме, переклин на огораживании от анонимусов и что там еще. И несмотря на это - абсолютно ушибленная аудитория, на фоне которой опеннетчики, пожалуй, не такие уж плохие. Ну так, в сравнении...
Rfkill не то?
> Rfkill не то?Как сказать? Это как кот Шреденгера. И то и не то. В принципе - он это делает. Но вопрос в том как.
Во первых, сам по себе он standalone программа. Мне не очень нравится идея выполнять внешнюю программу, сообщение в шину, анонсирующее system-wide что будет так-то и так-то было бы как-то логичнее. А там пусть менеджер сетевой конективити зовет его, если хочет (nm как-то так и делает).
Во вторых, просто #$%нуть интерфейс rfkill-ом - интерфейс то конечно #$%нется, спору нет. Но это никак не анонсируется остальным и для всех остальных это станет неожиданностью. Из под них просто грубо вышибут интерфейс без какого либо оповещения. А вот это называется словом "хреновый дизайн велосипеда".
На лоре уже обсуждали эту проблему:
https://www.linux.org.ru/forum/development/10756114
> через неработающий с sysfs inotify илиИли пофиксить наконец ай/фанотифай и неплодить лишних сущностей?
Но нет, мы не ищем легких путей! Чтобы ускорить дбас, нужно зафигачить его в ядро, а не редизайнить (как, кстати, и предлогал Линус)!! И продолжать пихать все возможное в этот самый д-бас!
У sysfs существует несколько проблем при использовании в качестве универсальной системной шины - насколько они реальны или надуманны - решайте сами, большинство обсуждалось недавно в комментариях к https://lwn.net/Articles/641275/
> У sysfs существует несколько проблем при использовании в качестве универсальной
> системной шины...главная из которых - что оно на системную шину похоже не более чем мотороллер похож на самосвал.
Мне не нравится в этой идее то, что юзерспейсные события через sysfs не пустишь - и в результате приложение всё равно должно тащить ещё какой-то механизм. А в D-Bus можно уместить всё, даже если их будет два - один системный, другой пользовательский, то кодовая база одна и та же и логика обработки - тоже.
> Мне не нравится в этой идее то, что юзерспейсные события через sysfs
> не пустишь - и в результате приложение всё равно должно тащить
> ещё какой-то механизм.Как уже отметили, sysfs - не система передачи сообщений. Это система работы с устройствами/драйверами, со своими задачами она справляется хорошо. Драйвера (за редким исключением) вообще не посылают событий, поэтому наворачивать d-bus повер sysfs очень странная идея.
> А в D-Bus можно уместить всё, даже если
> их будет два - один системный, другой пользовательский, то кодовая база
> одна и та же и логика обработки - тоже.1. По факту системная шина реально нужна очень небольшому числу приложений.
2. У sysfs и d-bus разные задачи и каждый должен заниматься своим делом, их смешение только сделает систему еще более запутанной.
Я иду с другой стороны. Есть приложения, которые заинтересованы в событиях от датчика - вполне возможно, как-то обработанных, кстати. Из доступных механизмов D-Bus на роль такого транспорта подходит отлично - он хорошо структурирован, на события легко подписаться, и инициирует эти события юзерспейсный демон, с которым легко что-то сделать - сэмулировать событие, добавить какие-то обработки, логирование и т.д. Альтернатива здесь - только какой-то, опять-таки, юзерспейсный, самопал на сокетах или чем-то подобном, но никак не sysfs - и писать самопал, когда есть готовое рещение - глупость.И я, честно говоря, не могу понять, кому ещё могут быть нужны сообщения от датчика кроме пользовательского приложения. Что до нужности - ох, не уверен. Подключение/отключение батареи, веб-камеры, монтирование разнообразных FS - это всё именно пользовательскому софту интересно прямо сейчас. Железные проблемы - тоже повод для реакции, скажем, торрентокачалки. А если пофантазировать насчёт того, что могло бы по этой шине ещё рассылаться - то это, например, оповещения о нехватке памяти - сейчас же, насколько я понимаю, вообще нет способа сказать приложению "мы тут в своп собираемся, может, ты можешь отдать часть памяти?". То же самое - насчёт нагрузки процессора или, тем паче, включившегося троттлинга. И так далее, и тому подобное.
А события - они и есть события. Я не вижу смысла реализовывать в приложении один механизм чтобы узнать о том, что интернет доступен, а другой - чтобы узнать, что руку к устройству поднесли. События должны быть унифицированы на более низких уровнях.
Более того - в sysfs датчики висят совершенно лысыми. Информации о том с какой их скоростью имеет смысл опрашивать - нет. Информации о разрешении датчика - нет. Информации о диапазонах - нет. Полезных ископаемых нет. Населена роботами.
> Вместо того чтоб вылезать из тоннеля, продвинемся еще немного вглубь.Ну так ты же не запилил более удачную шину для IPC, поэтому пользуются тем что есть.
> Логично.
> Вместо того чтоб вылезать из тоннеля, продвинемся еще немного вглубь. Логично.Ну это ж гномы. :)
> Без D-BUS-то ну совершенно же никак этого невозможно было сделать.Так вон датчики в sysfs висят. Или ты можешь напрямую по I2C с ними коммуницировать.
...только это нифуя не удобно для апликух сталкивающихся с неопределенным набором датчиков на неизвестной системе, но желающих допустим экран вертеть по показаниям акселя. Если девайс держат вертикально - то и экран в режим портрета. А если горизонтально - в режим ландшафта. А так то да, можно самому по I2C из акселя эти данные вытягивать. Почитав даташит на мег и узнав как работать с вот этим конкретным чипом. А вон тот соседний чип - лыко, мочало, начинай сначала.
> ...только это нифуя не удобно для апликух сталкивающихся с неопределенным набором датчиков
> на неизвестной системе, но желающих допустим экран вертеть по показаниям акселя.И как это решит iio-sensors? Как он узнает какой датчик - акселерометр? Почему тоже самое нельзя сделать в sysfs (создать отдельную директорию где будут только акселерометры)?
То есть вы предлагаете запихнуть это в ядро, хотя без малейших потерь всё можно сделать в юзерспейсе - в том числе обновлять базу устройств независимо от ядра.
Так драйвера уже в ядре. И есть уже /sys/class - добавить туда новые категории не проблема.
Ну так вы уж решите - то ли "как он узнает, какой датчик - акселерометр", то ли всё уже есть.
Я предлагаю, что бы драйвер регистрировал себя в /sys/class.
Если этого не сделать, то "как он узнает, какой датчик - акселерометр"? Будет тянуть отдельную базу, которую нужно будет обновлять вместе с ядром и не будет возможности узнать класс устройства без iio-*/systemd/d-bus?
Ну пусть регистрирует. Удобным для пользовательских приложений sysfs от этого не станет, и гибкую конфигурируемую логику не прибретёт. А так как скоростными такие штуки не бывают, лучшее, что можно для них сделать - юзерспейсный демон, который можно легко модиифцировать, отлаживать, мониторить, и который будет отдавать данные в удобном виде по стандартному интерфейсу, всё равно используемому приложениями для вагона других задач.
> Удобным для пользовательских приложений sysfs от этого не станетЕсли поверху sysfs поставить d-bus, то что это даст? Тем более, что драйвера редко работают в режиме событий (а если и работают - есть inotify). Чем d-bus более удобен, чем чтение/запись файлов при работе с устройствами?
> гибкую конфигурируемую логику не прибретёт
А должен? Я думал, что для это задача приложения.
> А так как скоростными такие штуки не бывают, лучшее, что можно для них сделать - юзерспейсный демон, который можно легко модиифцировать, отлаживать, мониторить, и который будет отдавать данные в удобном виде по стандартному интерфейсу
Так sysfs это уже стандартный интерфейс для работы с железом. Зачем конкретно нужен этот демон?
Удобен? Да всем. От того, что это таки события, а поллинг мы сваливаем на демон, до того, что он с вероятностью и так есть, и воткнуть в event loop ещё один обработчик - не проблема. И, разумеется, тем, что всё железоспецифичное мы оставляем деомну, а приложение получает логические события. Разница - как между сканкодами и кодами клавиш после всех обработок - повтора, раскладки, одиификаторов, переопределений и т.д.И нет, конфигурация - далеко не всегда дело приложения. А лучше - чтобы вообще им не была. Канфигурация - дело DE, фреймворка, рабочей среды - в общем, всего того, что объединяет разрозненные куски кода, умеющие делать каждый своё, в целое, рассчитанные под конкретные задачи и условия пользователя. То самое tools, not policy. К примеру, приложение получает сообщение "нажали на кнопку" - а какой логикой и где был подавлен возможный дребег - это не его дело. А вот где-то в конфигурации может быть прописано, то ли реагировать на малейшее прикосновение, то ли на уверенное нажатие в секунду.
А демон - нужен, именно потому что sysfs - это интерфейс для работы с железом. А приложению на железо начхать - оно работает с событиями, разделёнными на какие-то классы, имеющими какие-то свойства и т.п. И если смотреть не с точки зрения построения системы, а с точки зрения решения задач - нет никакого великого смысла держать железные события как что-то особенное, тем более - с отдельным интерфейсом.
> Удобен? Да всем. От того, что это таки события, а поллинг мы
> сваливаем на демон,Кто и как будет определять, что и как часто нужно опрашивать?
> И, разумеется, тем, что всё железоспецифичное мы оставляем деомну,
Несогласен - всё железоспецифичное - драйверу.
> а
> приложение получает логические события. Разница - как между сканкодами и кодами
> клавиш после всех обработок - повтора, раскладки, одиификаторов, переопределений и т.д.Для этого есть драйвера или библиотеки над ними.
> И нет, конфигурация - далеко не всегда дело приложения. А лучше -
> чтобы вообще им не была. Канфигурация - дело DE, фреймворка, рабочей
> среды - в общем, всего того, что объединяет разрозненные куски кода,
> умеющие делать каждый своё, в целое, рассчитанные под конкретные задачи и
> условия пользователя. То самое tools, not policy. К примеру, приложение получает
> сообщение "нажали на кнопку" - а какой логикой и где был
> подавлен возможный дребег - это не его дело. А вот где-то
> в конфигурации может быть прописано, то ли реагировать на малейшее прикосновение,
> то ли на уверенное нажатие в секунду.Это должно определяться в драйвере и управляться через sysfs. Для удобства пользователя можно поверху запустить gui/cli.
> А демон - нужен, именно потому что sysfs - это интерфейс для
> работы с железом. А приложению на железо начхать - оно работает
> с событиями, разделёнными на какие-то классы, имеющими какие-то свойства и т.п.Ну получите вы те же самые свойства, но в виде сообщений - все равно их придется унифицировать и обрабатывать. Не лучше ли унифицировать все на уровне sysfs?
> И если смотреть не с точки зрения построения системы, а с
> точки зрения решения задач - нет никакого великого смысла держать железные
> события как что-то особенное, тем более - с отдельным интерфейсом.В том и проблема, что в большинстве своем это не события. Если все перевести в события - будет большой overhead. Да и в любом случае будет overhead. Вы же не согласитесь с обычной файловой системой работать через d-bus? Так сказать в целях унификации интерфейсов ;)
> Кто и как будет определять, что и как часто нужно опрашивать?По нормальному - сделать параметром который можно заказать. Если клиент X хочет 1 раз в секунду, а клиент Y хочет 2 раза в секунду, читаем 2 раза в секунду, но одному отдаем все отсчеты а второму через один. А если они это будут делать независимо, в хучшем случае они будут дергать датчик не 2 а 3 раза в секунду.
> Несогласен - всё железоспецифичное - драйверу.
Это идеальный случай. Реально совсем ничего не знать о свойствах железки, пределах измерений, максимальной частоте измерений и прочая - юзермоду может быть тяжко.
Вот вижу я аксель. А вот я у меня игрушечный вертолетик которым я порулить с смарта хочу, используя этот аксель. Как мне в программе понять - годятся ли хоть в первом приближении параметры акселя? Это таки специфика железки и драйвера, но их было бы неплохо узнать. В плане диапазонов значений а также скорости и латенси получения отсчетов.
> все на уровне sysfs?
Делать из ФС шину - ну совсем не просто. Как максимум получится кривой франкенштейн. Оно годится как некая low level подложка, но для обычных апликух с ним довольно много мороки, особенно когда вопрос в том "а какие градусники есть и что они показывают?".
> любом случае будет overhead. Вы же не согласитесь с обычной файловой
> системой работать через d-bus? Так сказать в целях унификации интерфейсов ;)Мне кажется переклин на тотальной унификации интрфейсов - ведет к контрпродуктивным запрыгам по граблям, когда гвозди начинают завинчивать отверткой. В целях унификации.
> Если поверху sysfs поставить d-bus, то что это даст?Возможность получения интересующей информации без двух десятков служебных микро-операций.
> Чем d-bus более удобен, чем чтение/запись файлов при работе с устройствами?
Тем что файловые операции и pub/sub принципиально разные вещи.
Вот например акселерометр. А вот пачка программ, которым нехило бы знать - портретный режим или ландшафтный стоит сейчас отображать.
Вы как, предлагаете всем программам переться читать аксель самим, обрабатывать его данные и на этом основании делать вывод? Или все-таки пусть один демон прожует это, а потом кому надо - данные с акселя разошлет, а кому попроще - просто кинет мсг вида "ориентация экрана изменилась".
> А должен? Я думал, что для это задача приложения.
Ага, вот ща мы будем учить читалку пдфников жевать RAW отсчеты из акселерометра чтобы понять в какую сторону рендерить текст. Самому то не смешно?!
> Так sysfs это уже стандартный интерфейс для работы с железом. Зачем конкретно
> нужен этот демон?Затем чтобы объединять железо и приложения более высокоуровнвыми интерфейсами. Не комильфо читалке пдфников RAW отсчеты с акселя парсить!
>> Если поверху sysfs поставить d-bus, то что это даст?
> Возможность получения интересующей информации без двух десятков служебных микро-операций.Очень сомневаюсь. Приведите пример одного и второго решения.
> Вот например акселерометр. А вот пачка программ, которым нехило бы знать -
> портретный режим или ландшафтный стоит сейчас отображать.
> Вы как, предлагаете всем программам переться читать аксель самим, обрабатывать его данные
> и на этом основании делать вывод? Или все-таки пусть один демон
> прожует это, а потом кому надо - данные с акселя разошлет,
> а кому попроще - просто кинет мсг вида "ориентация экрана изменилась".Неправильно поставлена задача. Этим программам не нужен акселерометр. Более того им не нужно знать какой сейчас режим (портретный/ландшафтный). Все что им нужно - уведомление о смене разрешения окна/экрана. За это должен отвечать xorg/wayland/mir/etc. Они же должны повернуть отдаваемое приложением изображение на нужное количество градусов.
> Очень сомневаюсь. Приведите пример одного и второго решения.Как бы вам сказать? Я пробовал сделать обход "градусников" через sysfs. И таки подзадолбался. Если гномеры попробуют это сделать менее геморно - я только за. В sysfs очень дубовый интерфейс, он сгодится если я знаю что "хочу вот именно этот датчик". А вот generic обход в произвольной системе, с пониманием что это за датчик и прочее...
> уведомление о смене разрешения окна/экрана. За это должен отвечать xorg/wayland/mir/etc.
> Они же должны повернуть отдаваемое приложением изображение на нужное количествоНу во первых, уведомление о смене разрешения один фиг должно ехать через нечто bus-образное.
Во вторых, "просто повернуть изображение" было бы слишком просто. Де факто многие программы должны как минимум еще сделать ре-рендер документа под новый формат сторон, чтобы это не смотрелось как кусок блeвотины, явно понимая что они рендерят под другое соотношение сторон экрана.
В третьих, в гробу я видал чтобы xorg, wayland и прочие применяли решение о том когда крутить экран. Это должен делать некто иной. Работающий с акселем. Или чем там еще. И имеющий возможность высказать свое мнение о всем этом неопределенной группе подписчиков которых это может интерсовать. Ну то-есть xorg или wayland вполне могут быть одним из клиентов события "ориентация экрана изменилась", почему бы и нет. И даже что-то сделать по этому поводу. Но вот отнюдь не их дело читать RAW показания акселерометра и принимать решения об ориентации. А вот это решение - иксам, вялендам и проч. тоже надо как-то отсигналить. Ну вот по логике вещей получается что логичнее всего пхнуть сообщение в шину, а все заинтересованные узнают что экран крутанулся.
>> уведомление о смене разрешения окна/экрана. За это должен отвечать xorg/wayland/mir/etc.
>> Они же должны повернуть отдаваемое приложением изображение на нужное количество
> Ну во первых, уведомление о смене разрешения один фиг должно ехать через
> нечто bus-образное.Там уже есть своя система событий.
> Во вторых, "просто повернуть изображение" было бы слишком просто.
Не нужно усложнять, тогда все и будет просто.
>Де факто многие
> программы должны как минимум еще сделать ре-рендер документа под новый формат
> сторон, чтобы это не смотрелось как кусок блeвотины, явно понимая что
> они рендерят под другое соотношение сторон экрана.Я же сказал - "Все что им нужно - уведомление о смене разрешения окна/экрана."
Было 800x600, стало 600x800. Программа просто заново разместит виджеты и подгонит их размер.> В третьих, в гробу я видал чтобы xorg, wayland и прочие применяли
> решение о том когда крутить экран. Это должен делать некто иной.Этим занимается xorg (конкретно xrandr) - только он может повернуть все окна и приложениям не придется думать под каким углом рисовать виджеты.
> Работающий с акселем. Или чем там еще. И имеющий возможность высказать
> свое мнение о всем этом неопределенной группе подписчиков которых это может
> интерсовать.Приложению должно быть абсолютно вее равно, почему изменилось разрешение. Может произошла смена видео режима или был подключен новый монитор или монитор был повернут.
> Ну то-есть xorg или wayland вполне могут быть одним из
> клиентов события "ориентация экрана изменилась", почему бы и нет. И даже
> что-то сделать по этому поводу. Но вот отнюдь не их дело
> читать RAW показания акселерометра и принимать решения об ориентации. А вот
> это решение - иксам, вялендам и проч. тоже надо как-то отсигналить.
> Ну вот по логике вещей получается что логичнее всего пхнуть сообщение
> в шину, а все заинтересованные узнают что экран крутанулся.Зачем обычному приложению заниматься поворотом виджетов самому, если эту работу может выполнить графическая подсистема?
а нормальный ДЕ у них в планах хоть есть?
Да уж давным-давно сделали. Зачем к этой теме возвращаться? Gnome2 называется.
Мне вот интересно, Вас какая собака укусила? Или Вы считаете что Ваш вкус на конкретный DE - эталон для всех? После привязки Gnome3 с какой-то там подверии к SystemD переехал на KDE, и ни разу не впечатлен этим, позвольте сказать, салатом из виджетов и хрен пойми чего откуда вылезающих окошек. По мне, так строгий и изящный, простой интерфейс Gnome 3 куда удобней двухчасового передвигания панелей туда-сюда и нажиманий 1000 кнопок "Настройка" в самых неожиданных местах. Но нет жеж, по Вашему мнению, таких людей в природе нет, нет таких, которые бы предпочитали Gnome KDE. Даже не буду говорить про неудобство пользования KDE на планшетах и ноутбуках трансформерах.
Золотой наш, переезжай на Lumina http://www.opennet.me/opennews/art.shtml?num=42147
Ни тебе systemd, ни настроек KDE - благодать!
А то KDE уже тоже завязывается на systemd.
Штоо? Ну епт. Ну это вообще... ну переедем, че поделать та теперь? =)
> Мне вот интересно, Вас какая собака укусила? Или Вы считаете что Ваш
> вкус на конкретный DE - эталон для всех? После привязки Gnome3
> с какой-то там подверии к SystemD переехал на KDE, и ни
> разу не впечатлен этим, позвольте сказать, салатом из виджетов и хрен
> пойми чего откуда вылезающих окошек.То, что Вы сходу не разобрались с концепцией DE от KDE - не удивительно. Многие с этим сталкивались. Она, судя по всему, сильно отличается от Gnome. А Вы к нему привыкли. Посидите ещё месяцок-другой, может быть Ваш рабочий процесс войдёт в привычное русло.
> По мне, так строгий и изящный,
> простой интерфейс Gnome 3 куда удобней двухчасового передвигания панелей туда-сюда и
> нажиманий 1000 кнопок "Настройка" в самых неожиданных местах.Это старый известный баланс между удобством и возможностью подёргать маленькие рычажки для глубокой настройки. Вот некоторые и вовсе Emacs используют - именно из-за этих рычажков, ибо я не видел операционной среды, где бы их было ещё больше.
> сходу не разобрались с концепцией DE от KDEЯ лет пять "разбирался с концецией" после того как они выпустили KDE4. Максимум вот удалось 4 месяца непрерывно на это "любоваться", не выдержал в конце концов, теперь даже в их сторону смотреть неохота. Как-было разваливающийся кривой гирляндой так и осталось.
PS: бывший любитель 3-ых кед
А, мы про KDE4? Ну да, про них тоже кричали много. Сам-то я только KDE3 видел. Они были более-менее ничего. Как и XFCE4, кстати. Gnome уже тогда был немного громоздким.Сейчас, боюсь, мне нечего ответить на критику KDE в плане 4й версии, ибо во-первых я последние кеды не юзал, а во-вторых уже давно перешёл на i3wm.
Актуальная версия KDE Plasma - 5.
а KDE5 <=> KDE5 или как обычно?
i3wm попса как и кде с гномом
Может и попса, но обеспечивало почти прозрачный переход с wmii3 и решало многие проблемы.
> То, что Вы сходу не разобрались с концепцией DE от KDE -
> не удивительно. Многие с этим сталкивались. Она, судя по всему, сильно
> отличается от Gnome. А Вы к нему привыкли. Посидите ещё месяцок-другой,
> может быть Ваш рабочий процесс войдёт в привычное русло.Месяц? Я им уже второй год пользуюсь. И я не говорил что я не могу в нем работать или что я чего-то не понимаю. Я говорю про впечатление от KDE4 в целом. Я вот х3 во всех дистрибутивах линукса так или только в моем, или только у меня, но эти виджеты при активной настройки глючат, начинаешь их ерзать, они начинают уезжать куда-то или вовсе пропадать, и, в итоге, из юзабельного в KDE4 остается только одна панель с кнопокй меню запуска приложений, и тому подобное. И настроек уж слишком много, при чем дублирующих. Настроил в системных настройках время и раскладку и тоже самое нужно сделать в виджетах. Тогда зачем это делать в системных настройках?
> Это старый известный баланс между удобством и возможностью подёргать маленькие рычажки
> для глубокой настройки. Вот некоторые и вовсе Emacs используют - именно
> из-за этих рычажков, ибо я не видел операционной среды, где бы
> их было ещё больше.Ну, насколько я помню, в Gnome, даже во второй версии эти механизмы дергания за рычаги были. Только не ввиде кнопок по всюду, а через gconf что ли =) Точно не помню как оно там называлось.
> отличается от Gnome. А Вы к нему привыкли. Посидите ещё месяцок-другой,
> может быть Ваш рабочий процесс войдёт в привычное русло.А не сильно ли дофига пару месяцев под DE дрессироваться? :)
мне вообще хоть кто-нибудь ответит как дела у гнума3 со стабильность? Я так понял каждые пол-года "стабильный" релиз??? Именно поэтому многие забивают переписывать темы и дополнения (без которых гном просто неюзабелен).
Как вообще можно пользоваться "управлялкой окон", если каждые пол-года приходится переучиваться???
> Именно поэтому многие забивают переписывать темы и дополненияНасколько понимаю, это следствие не "стабильных" релизов, а как раз сознательного слома соответствующих интерфейсов таким образом, чтоб авторы сторонних тем задолбались их тащить -- поскольку апстримное отношение "мы сделали тему и она хороша, а вы со своими поделками только распыляете наш продухт". Темой по умолчанию пользоваться можно, тем не менее.
> Даже не буду говорить про неудобство пользования
> KDE на планшетах и ноутбуках трансформерах.А что скажете по поводу https://bugzilla.gnome.org/740554?
>> Даже не буду говорить про неудобство пользования
>> KDE на планшетах и ноутбуках трансформерах.
> А что скажете по поводу https://bugzilla.gnome.org/740554?Даже не смотрел что за баг по ссылке, и вот почему: ошибку в итоге исправят, а в kde4 как была неюзабельная концепция, так и останется. В то время как концепция организации окошек в Gnome уже готов для использования на маленьких недобуках с тачскрином.
> уже готов для использования на маленьких недобуках с тачскриномНи одного такого не припоминаю. А баг посмотрите, он совершенно изумительный для интерфейса, который всю дорогу колотил себя пятою в грудь насчёт планшетов...
>> уже готов для использования на маленьких недобуках с тачскрином
> Ни одного такого не припоминаю.Кого не припомните? Ноутбука с тачкрином? Dell XPS 12 например, или линейка Lenovo Yoga. Может в KDE 5 что-то и лучше станет, но в текущей версии максимум что можно сделать - это переключить в режим ноутбука, но при этом рабочий стол превращается в неюзабельное тормозное ... месиво =)
> А баг посмотрите, он совершенно изумительный
> для интерфейса, который всю дорогу колотил себя пятою в грудь насчёт
> планшетов...А кто такой awesomebar? =) Насколько я понял людей заставляют два раза нажать кнопку что бы перейти по ссылке вбитой в этот самый awesomebar. Ну бывает, ну поправят, они же не говорят, что это не баг, а фишка и что так и должно быть =) В то время как в других багтраках подобных проблем нет? :)
В общем резюмируя всю простыню комментариев хочу сказать следующее:
Люди, которые заявляют что Gnome - говно, а kde рулееzz - не правы, так как они не одни в мире и есть люди, которым нравится оформление, стиль и подход примененный в Gnome - Я например. Хоть я и перешел с Gnome после того как с ним случился systemd на KDE, в котором тоже много багов похлеще чем тут https://bugzilla.gnome.org/show_bug.cgi?id=740554, но все равно уверен, что в Gnome наиболее интересный подход к организации рабочего стола. Ждем когда KDE5 перейдет в stable и попробуем его, может там будет лучше +)
>>> уже готов для использования на маленьких недобуках с тачскрином
>> Ни одного такого не припоминаю.
> Кого не припомните? Ноутбука с тачкрином? Dell XPS 12 напримерЭто ультрабук/трансформер по нынешней классификации, насколько понимаю.
> А кто такой awesomebar? =) Насколько я понял людей заставляют два раза
> нажать кнопку что бы перейти по ссылке вбитой в этот самый
> awesomebar. Ну бывает, ну поправят, они же не говорят, что это
> не баг, а фишка и что так и должно быть =)Это поле ввода адреса/ключевых слов в Firefox, но с Epiphany то же самое.
> В то время как в других багтраках подобных проблем нет? :)
Это *блокер* для возможности пользоваться браузером на планшете. Да, я пробовал.
>>>> уже готов для использования на маленьких недобуках с тачскрином
>>> Ни одного такого не припоминаю.
>> Кого не припомните? Ноутбука с тачкрином? Dell XPS 12 например
> Это ультрабук/трансформер по нынешней классификации, насколько понимаю.Во-первых: классификаторы продавца и покупателя могут отличаться :)
А во-вторых: я так и сказал, недобук/трансформер. А вот этот чемодан http://www.dell.com/us/p/alienware-17-r2/pd иначе как моноблок тяжело назвать :) Но это все шутки.>> А кто такой awesomebar? =) Насколько я понял людей заставляют два раза
>> нажать кнопку что бы перейти по ссылке вбитой в этот самый
>> awesomebar. Ну бывает, ну поправят, они же не говорят, что это
>> не баг, а фишка и что так и должно быть =)
> Это поле ввода адреса/ключевых слов в Firefox, но с Epiphany то же
> самое.
>> В то время как в других багтраках подобных проблем нет? :)
> Это *блокер* для возможности пользоваться браузером на планшете. Да, я пробовал.Ну блокер, ну да. Ну проблема та в чем? Что вы пытаетесь донести? Можно прямым текстом уже сказать для тупых? :)
> Ну блокер, ну да. Ну проблема та в чем? Что вы пытаетесь
> донести? Можно прямым текстом уже сказать для тупых? :)В том, что искорёженный "под тачскрин" гном успешно игнорирует блокер, который вряд ли бы вообще был повешен несколькими сторонними разработчиками (см. дубли бага), если бы кто-нить в проекте вообще озадачивался такими пустяками как проверка пригодности на заявленной UI-платформе. Чай ведь не 3.0 и даже не 3.4 уже.
Странно мне это.
Gnome с каждым разом тортее и тортее
\\Из требуемых для работы iio-sensor-proxy зависимостей отмечаются libgudev и systemd.Последнее то зачем? Совсем с ума посходили с этим мегамонстром.
Затем, что это и было основной целью. Привязать как можно больше всего к systemd.
А кде?
Странно, почему при разработке iio не додумались сделать классификацию устройств в драйверах, чтобы, как обсуждали выше, доступ ко всем датчикам температуры происходил через /sys/class/temperature/* И удобно, и всяким велосипедам вроде iio-sensor-proxy не нужно догадываться о типе датчика.
iiO, говорите?
