LINUX.ORG.RU

ConnMan 1.0

 , ,


2

1

Марсель Холтман (Marcel Holtmann) 8 мая 2012 года объявил о выходе стабильного релиза ConnMan.

ConnMan — служба для управления интернет-соединениями во встраиваемых Linux-устройствах. Первоначально была разработана Intel в рамках проекта Moblin.

Начиная с версии ConnMan 1.0 D-Bus API объявлено стабильным. В дальнейшем планируется только расширять функционал API, что позволит поддерживать обратную совместимость для последующих версий ConnMan.

Стабилизация D-Bus API и послужила поводом для объявления релиза стабильным и перехода на нумерацию версий «1.х».

>>> Подробности



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

Когда-то пробовал, но не ощутил никаких прелестей. По сравнению с 0.8 какие-то изменения к лучшему есть?

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

The ConnMan project provides a daemon for managing internet connections within embedded devices running the Linux operating system. The Connection Manager is designed to be slim and to use as few resources as possible, so it can be easily integrated. It is a fully modular system that can be extended, through plug-ins, to support all kinds of wired or wireless technologies. Also, configuration methods, like DHCP and domain name resolving, are implemented using plug-ins. The plug-in approach allows for easy adaption and modification for various use cases.

Разницы с NetworkManager'ом не нашёл, за исключением этого:

The Connection Manager is designed to be slim and to use as few resources as possible, so it can be easily integrated./quote]

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

Да всё я читал, и даже по ссылке сходил.

Ведь можно сказать и так:«ConnMan ― это альтернатива NetworkManager'у для встраиваемых систем, отличающаяся от последнего меньшими требованиями к системным ресурсам.»

Налицо демон в фоне, модульность, возможность создавать / использовать плагины, одинаковое назначение двух программ.

carasin ★★★★★
()

присоединится к разработке нетворк менеджера - нет. свой велосипед писать - да! фейспалм.джпег

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

Не, не будем. Нелюбитель я сраться. Просто это одного поля ягоды, а из текста новости я этого не понял.

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

Мнение арчвики не является окончательным. нетворкменеджер давно стал эталоном и идеалом?

Все-таки настаиваите на нетворкоменеджеросраче?

В чем смысл «нужно - не нужно, альтернатива - не альтернатива, замена - не замена»?

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

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

присоединится к разработке нетворк менеджера - нет. свой велосипед писать - да! фейспалм.джпег

конкуренция нужна.

kernel ★★☆
()

nm не нужен. Connman'ом пользовался на нетбуке с E17. В принципе неплохо, но пилить его еще надо. Стабилизация D-Bus API радует.

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

ну так форкнуть проект и вести разработку в сторону встраиваемых систем. и конкуренция и старые наработки сохранены. но по ссылке - чистый велосипед

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

Я никогда не говорю «не нужно». На арчевики по этому поводу я не заглядывал (цитата была с оф. сайта проекта). Про маргиналов и их мнение ― то вообще мимо.

Просто хотел указать на то, что из текста новости не понятно, что это, зачем оно и с чем его едят. Срачи не люблю.

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

в лучших традициях комментарий «сперва добейся». я не работаю в этой области. а как пользователь я не доволен таким ходом дела

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

Мальчик, вы адекватны? Я цитату откуда привёл по-вашему?

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

Вам указали на то, что вы неправы. Отвечайте по существу. Чем оно отличается от НМ и почему не замена?

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

А в чем недовольство? Вы пользовались ConnMan? В чем его проблемы? В чем неудобства? В чем удобства?

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

ну так форкнуть проект и вести разработку в сторону встраиваемых систем. и конкуренция и старые наработки сохранены. но по ссылке - чистый велосипед

Вы как будто программ не писали сложных никогда. Если вы меняете некие базовые решения заложенные в дизайн - *гораздо* проще написать новую программу. И так кстати делают даже если пишут одну программу - называется «переписать с нуля». Более того - если вы пишете чтото где нужна часть возможностей в экзотичных условиях - проще именно с нуля, так как можно постепенно вписывать программу в специфические условия, реализуя в начале простые фичи.

А тут у нас класический случай эволюции - под линуксом networkmanager первая(?) реализация менеджера сети. То есть предполагается по сути, что после написания альтернатив и конкуренции между ними, в конце концов выиграет сильнейшая - и это не обязательно будет потомок nm.

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

Нет. Объект полностью описан по ссылке. Новость не подразумевает написание статей в формате Wikipedia или полный перевод сайта программы или многостраничный обзор. Новость также не подразумевает эмоциональных характеристик от автора или необоснованных сравнений.

Новость прочитали - заинтересовало - нажали на ссылку - разбираетесь дальше.

Алгоритм такой.

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

*гораздо* проще написать новую программу

в случае если говнокод иначе проще отрефакторить. не обязательно *первая* реализация должна быть говнокодом

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

в случае если говнокод иначе проще отрефакторить. не обязательно *первая* реализация должна быть говнокодом

NM ужасен и крив. Мне, лично, только ломал сеть, например.

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

в случае если говнокод иначе проще отрефакторить. не обязательно *первая* реализация должна быть говнокодом

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

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

В случае FOSS-же и в случае любой нестандартной разработки - в принципе неверное предположение.

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

потому, что поделки systemd, dbus, nm, pulseaudio традиционно подлежат торжественному захоронению

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

базара нет что можно. но я все же считаю что если лицензия совпадает то лучше сохранять старый код и апи сильно не менять. вот такой у меня старо-пердунский взгляд на программирование :P

punya ★★
()

NetworkManager для роутеров? В чём его преимущества перед классическими схемами?

Quasar ★★★★★
()

отлично. надеюсь скоро будет на десктопе. а то засилье быстрописаных толстых программ напрягает.

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

Вот честно не могу как хомячёк балующийся sh-скриптами не вижу в d-bus ничего хорошего. Так, ещё одна дырка.

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

Я не про реализацию, а про однотипность двух программ.

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

D-Bus - это же unix way для гуя. В последнее время на десктопе отметилась тяга к демонизации всего и вся. Тот же NM, Unity, индикаторы, апплеты панелей, session manager'ы, Zeitgeist, и т.д. А ещё с помощью D-Bus удобно писать всякие макросы-скрипты для управления гуёвыми программами.

...Кто тут сказал «сетевая прозрачность»?

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

Тяга это такое явление, возникающее при разности давлений. Вот создающим эту разность я бы руки бы склеил. Для предотвращения.

А управление гуёвыми программами можно и через, ВНЕЗАПНО, командную строку. Демонизация это инструмент.

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

И UNIX-way for GUI не отличается от того же для ком строки. Просто вид другой примет. А ваш любимый D-Bus требует связывания со сторонней либой. А это уже Windows-way.

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

Для управления через командную строку управляющее приложение должно как-то доступиться до уже запущенного управляемого.

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

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

А ваш любимый D-Bus требует связывания со сторонней либой.

4.2, ничего он не требует. D-Bus - это просто протокол поверх сокетов. Никто не запрещает написать свою реализацию или слинковать libdbus статически, только зачем?

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

Ну как и говорил, ещё одна дырка. Да и зачем из другого приложения управлять то? Не вашу траву курить не буду. Она какая то стрёмная и подталкивает в сторону от NIX-way. Один Поттер чему яркий пример.

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

Ну не нравится libdbus, напишите реализацию протокола сами. Вон dbus-sharp не использует сишного кода и libdbus, всё на чистом шарпе.

Да и зачем из другого приложения управлять то?

Абсолютно банальный пример: браузеру требуется добавить новую закачку в запущенный download manager. Или новый RSS-фид в читалку. Как? Ну хорошо, сам браузер может запустить новый процесс менеджера или читалки и передать URL через командную строку, но этот новый процесс должен как-то а) определить, что уже выполняется другой процесс, б) передать ему команду с параметрами, в) завершиться.

Вот тут-то и приходит на помощь D-Bus. До него городили всякие нестандартные, десктопноспецифические недодбасы вроде DCOP.

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

dbus удобнее и его можно если сильно припрет но сети прокидывать хотя это и не штатная опция. И таки с помощью dbus'а тоже можно через командную строку прогами рулить.

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

но я все же считаю что если лицензия совпадает то лучше сохранять старый код и апи сильно не менять. вот такой у меня старо-пердунский взгляд на программирование :P

У вас не олдскульный взгляд а абсолютно бредовый :D

Грубо говоря для решения любой задачи есть два пути - адаптировать существующее решение или сделать свое. Каждый подход имеет свои достоинства и недостатки. А вы огульно отвергаете один подход в пользу другого.

А тут вообще говоря есть аргументы в пользу именно таких решений. API то по факту не устоялся, сетевой менегер для линукса шутка новая. То что он сейчас выглядит как NM а не как какое то другое решение, это чистая случайность.

Так что я тут за то что бы возникли конкурирующие решения написанные с нуля с какие то альтернативными подходами - и пусть поконкурируют. А когда все более менее определится - FDO выпустит стандарт на dbus интерфейс для этого всего, например.

PS
При этом вы например вы делаете совершенно необоснованное предположение что там лицензия совпадает. Судя по истории проекта эту штуку пилили глубоко внутри нокия для своих корпоративных нужд. Лицензия вообще у такой штуки может быть любая. Более того, в таких проектах вообще чаще всего двойное лицензирование и просто так чужие патчи не принимают.

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

И UNIX-way for GUI не отличается от того же для ком строки. Просто вид другой примет. А ваш любимый D-Bus требует связывания со сторонней либой. А это уже Windows-way.

Вы тогда сокеты запретите - они же до вхождения в стандарт шли сторонними либами.

Без dbus было бы гораздо хуже - вместо использования модульности программы начинали выдумывать свои велосипеды для простейших сейчас операций. И вырастали , и вырастают безумные комбайны вроде оперы с торрент клиентом или там пробегавшего тут изделия где броузер плюс все-все-все.

kernel ★★☆
()

Довольно косая поделка. Юзал на ноуте - вечно отваливается на отключении от WiFi, тупит если нет DHCP и вообще не айс.

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

Без dbus было бы гораздо хуже - вместо использования модульности программы начинали выдумывать свои велосипеды для простейших сейчас операций.

Может приведете здесь пример кода на C, решающий простейшую операцию через dbus. Без использования glib одно только общение через dbus тот еще геморрой. А надо еще сами сообщения в стиле а ля XML обрабатывать.

zloy_starper ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.