Разработчики проекта GNOME опубликовали (https://mail.gnome.org/archives/gnome-announce-list/2017-May...) первый выпуск утилиты gps-share, предназначенной для организации доступа к устройству GPS из других систем по локальной сети. Код проекта написан на языке Rust и поставляется (https://github.com/zeenix/gps-share) под лицензией GPLv2. В процессе работы gps-share задействованы библиотеке libdbus, libudev, libcap и xz-libs.При помощи gps-share можно организовать совместное использование GPS между несколькими устройствами, не имеющими собственных чипов для работы с GPS. Gps-share также нацелен на обеспечение поддержки обособленных GPS-устройств в сервисе определения местоположения Geoclue (https://www.opennet.ru/opennews/art.shtml?num=42992), наряду с уже поддерживаемыми источниками, такими как встроенные в смартфоны GPS-чипы (требует запуска на смартфоне специального приложения), а также публичные БД (https://wiki.mozilla.org/CloudServices/Location) размещения WiFi-сетей, базовых станций и провайдеров (GeoIP).
Gps-share позиционируется как замена проектам GPSD (http://www.catb.org/gpsd/) и Gypsy (https://gypsy.freedesktop.org/), также решающих задачу мультиплексирования доступа к данным GPS для нескольких клиентов. GPSD имеет серьёзные архитектурные проблемы (https://gypsy.freedesktop.org/why-not-gpsd.html) и ограничения (проект развивается с 1995 года), а Gypsy уже много лет находится в заброшенном состоянии. Создание нового проекта было признано более целесообразным, чем возрождение устаревшей и не поддерживаемой кодовой базы.
В настоящее время gps-share поддерживает работу только с GPS-устройствами, поддерживающими протокол на основе эмуляции последовательного порта (RS232). В частности, к ним относится большинство GPS-устройств, подключаемых через USB или Bluetooth. Для устройств с интерфейсом Bluetooth требуется ручная настройка порта при помощи утилиты rfcomm (например в Fedora 25 при подключении TomTom
Wireless GPS MkII нужно запустить "sudo rfcomm connect 0 00:0D:B5:70:54:75").
URL: https://mail.gnome.org/archives/gnome-announce-list/2017-May...
Новость: https://www.opennet.ru/opennews/art.shtml?num=46623
Хм... А совместное использование нескольких для уточнения результата?
Возникает вопрос, а причем тут gnome?
Gnome Positioning System, очевидно.
При том, что USB, /dev/tty*, /dev/rfcomm через сеть и так пробрасываются совершенно спокойно не зависимо от того, какое устройство туда подключено. Ну единственное с USB могут быть проблемы если общение с устройством завязано на таймауты, а сеть не успевает.
Совершенно простецкая и абсолютно бессмысленная поделка.
Ну нахрена мультиплексировать GPS если координаты всегда будут у того устройства, через которое все другие типа время получают точное? Идиотизм.
микросервисы. автомобили. самолёты.
какие нафиг микросервисы?
это не сеть передачи данных, это получение координат и точного времени, не более. а такие задачи первая - покажет координаты только устройства "прокси", второе - ну что мешает просто поднять NTP на этой "проксе" и синхронизировать всё по нормальнойй схеме?
Короче говоря, практического смысла не вижу никакого. Дурдом вижу. Типа языка программирования брейнфак.
Бывают такие потребности.
Например временное оборудование на судне, которое устанавливается в каютах или вообще во внутренних помещениях без иллюминаторов, и которое не может быть подключено к судовой системе GPS по соображениям безопасности или по соображениям экономии. Есть локалка, есть возможность поставить "эталонный" GPS. Точность координат в пределах размеров судна вполне устраивает. Вполне нормальное решение.
> Совершенно простецкая и абсолютно бессмысленная поделка.
> Ну нахрена мультиплексировать GPS если координаты всегда будут у того устройства, через
> которое все другие типа время получают точное? Идиотизм.Плывёт чёрный ящик, в нём один GPS приёмник и куча оборудования, которая предполагает что на него будет поступать откуда-то входной поток GPS данных. Не институт, на крыше которого стоит GPS и транслирует одну и ту же координату всем сотрудникам (хотя так тоже можно).
> Плывёт чёрный ящикА сотрудникам будет польза от того, что будут иметь информацию от координат GPS приёмника где-то там на крыше с точностью до пяти метров?
У нас в конторе, и я сам настраивал NTP stratum 3 (меньше - наглости не хватило) по гпс,ещё лет двенадцать назад. С координатами не заморачивался вообще. Цель то была совсем другая. Приёмник типа Wharton GPS. С ним табло идёт, по цепочке можно зафигачить до 64 штук, которые в нагрузку ещё локальную температуру показывают.
Модель старая, 4850 серия. Такую уже не выпускают, но она исправно работает.
>> Плывёт чёрный ящик
> А сотрудникам будет польза от того, что будут иметь информацию от координат
> GPS приёмника где-то там на крыше с точностью до пяти метров?Вот я специально написал что это не для института с сотрудниками.
Мало того что зависимостей куча, так ещё и на расте написано.Такие вещи нужно писать на си и без зависимостей совсем.
А Вы случайно не путаете RUST и RUBY?
Да не, это болезный си-господин, как же не бзднуть при виде другого языка.
Сам потом это компеляй и добавляй в порты.
Вместо того чтобы юзать проверенный временем стабильный язык который есть вообще везде берут хипстерскую поделку.
руст, го - наfиг это всё.
> Такие вещи нужно писать на си и без зависимостей совсем.Кому нужно? Вот он пускай и пишет без зависимостей. Хоть непосредственно в машинных кодах под голое железо. Только где он потом найдёт желающих пользоваться результатом: там где нет ОС, нет и приложений, которые хотят пользоваться gps. Ну, точнее такие места бывают, но там не бывает гномов, демонов, эльфов и орков. И из тех мест до opennet'а не доходят новости.
"Куча зависимостей" сводится к: libdbus, libudev, libcap и xz-libs. Из которых первые три потребуются обязательно, если смириться с существованием ОС и писать в юзерспейсе. Зачем там xz-libs и насколько они необходимы я не знаю, но как по мне для системной утилитки нормально хотеть чего-нибудь в этом роде. Помимо этого, есть зависимости специфичные для раста, перечисленные в Cargo.toml, но там тоже нет ничего лишнего. Обёртки над libdbus, libudev, реализация rfc232... Ну, может clap лишний: могли бы воспользоваться getopt из libc. Тут сложно разобраться -- это растовый NIH синдром, или реально вся эта возня с просовыванием через ffi строк между C и Rust не стоит того, проще заново написать всю функциональность непосредственно в rust. Не функциональность и была.
gpsd, хоть и безобразен, не требует libudev и lubdbus, посему работает чуть более, чем везде, в отличие от.
> gpsd, хоть и безобразен, не требует libudev и lubdbus, посему работает чуть
> более, чем везде, в отличие от.Везде это где? В венде? Зачем мне нужен gpsd в венде? Кому он вообще там нужен?
>> gpsd, хоть и безобразен, не требует libudev и lubdbus, посему работает чуть
>> более, чем везде, в отличие от.
> Везде это где? В венде? Зачем мне нужен gpsd в венде? Кому
> он вообще там нужен?При чем здесь винда? *BSD, старые юниксы, макось и т.д.
>>> gpsd, хоть и безобразен, не требует libudev и lubdbus, посему работает чуть
>>> более, чем везде, в отличие от.
>> Везде это где? В венде? Зачем мне нужен gpsd в венде? Кому
>> он вообще там нужен?
> При чем здесь винда? *BSD, старые юниксы, макось и т.д.Ах, эти... Кому они нужны?
Впрочем, если ты дашь себе труд сходить по ссылке, там прямо написано:
gps-share is targetted specifically for Linux. It may or may not work on other POSIX hosts. Patches to add/fix support for non-Linux systems, are more than welcome.
Напиши им патчи для поддержки хотплага gps-устройств в *bsd, и будет тогда для *bsd версия gps-share, которая не будет тянуть в депендансах libudev.
Макось... Я не знаю, что там в макоси, но мне кажется, что там всё сильно по-макосёвому, и из-за неё урезать функциональность линуксового софта -- это глупость. Если яблофилам будет надо, они портируют. Если им не надо, значит они тем более не обломаются.
Старые юниксы, где нет хотплага, пролетают фанерой над парижем: им не место на десктопе. Из-за их ограничений ограничивать возможности современного софта -- это глупость ещё большая, чем ограничивать эти возможности из-за совместимости с современной макосью. Пускай старые юниксы продолжают использовать безобразный gpsd. Им никто не запрещает.
>>>> gpsd, хоть и безобразен, не требует libudev и lubdbus, посему работает чуть
>>>> более, чем везде, в отличие от.
>>> Везде это где? В венде? Зачем мне нужен gpsd в венде? Кому
>>> он вообще там нужен?
>> При чем здесь винда? *BSD, старые юниксы, макось и т.д.
> Ах, эти... Кому они нужны?
> ...
> Старые юниксы, где нет хотплага, пролетают фанерой над парижем: им не место
> на десктопе.А вообще gpsd или там gps-share место на десктопе? Какой у него юзкейс на десктопе?
>[оверквотинг удален]
>>>>> более, чем везде, в отличие от.
>>>> Везде это где? В венде? Зачем мне нужен gpsd в венде? Кому
>>>> он вообще там нужен?
>>> При чем здесь винда? *BSD, старые юниксы, макось и т.д.
>> Ах, эти... Кому они нужны?
>> ...
>> Старые юниксы, где нет хотплага, пролетают фанерой над парижем: им не место
>> на десктопе.
> А вообще gpsd или там gps-share место на десктопе? Какой у него
> юзкейс на десктопе?Я неудачно выразился. Не "десктоп", а более широко: девайсы с гуём. Смартфон с gps-приёмником, и ноутбук без него. usb-донгл в ноутбуке в качестве gps-приёмника, и что-нибудь там как клиент gps-share.
Мне сложно представить себе где это может понадобиться вне устройств связанных с гуём. Ну, может быть, если я какой-нибудь квадрокоптер соберу, а потом от него буду его координаты получать. Хотя там всё равно придётся создавать какой-то другой канал передачи данных -- для прочей телеметрии и для управления, -- и по нему между прочим передать gps-координаты -- не такая уж и проблема.
Ну вот всё кроме xz-libs явно могло бы быть факультативным. Есть d-bus - пользуемся, нет - работаем только как TCP-сервер (раз уж "из других систем по локальной сети"). Есть ещё и libudev - ловим появление/исчезновение устройств (больше ж оно ни за чем не может быть нужно?), нет - берём из конфига (в любом случае нужен). Есть libcap - пользуемся, нет - работаем как есть. Но, понятно, гномоводы не привыкли делать так, всё прибивают на свой юз-кейс...
> Ну вот всё кроме xz-libs явно могло бы быть факультативным. Есть d-bus
> - пользуемся, нет - работаем только как TCP-сервер (раз уж "из
> других систем по локальной сети").А они разве между хостами передают по TCP, а не через dbus? Не, если это действительно так, то я соглашусь и подпишусь под утверждением, что авторы идиоты. Но поскольку они не выглядят для меня идиотами, я скорее предположу, что они коннектятся к dbus-демону на удалённой машине и весь IPC гонят через dbus.
> Есть ещё и libudev - ловим
> появление/исчезновение устройств (больше ж оно ни за чем не может быть
> нужно?), нет - берём из конфига (в любом случае нужен).Можно, наверное. Не вижу глубинного смысла: по-моему, это лишь ненужное усложнение кода. Если начать работать с конфигом, то начнутся проблемы типа "конфиг не найден", "синтаксическая ошибка в конфиге", "девайс не найден", "девайс выдернули из гнезда", ... То что в случае hotplug не проблема, а рабочая ситуации, в случае с конфигом превратится в наслоения кода обработки ошибок. И зачем мне эти наслоения кода, если у меня есть libudev?
Впрочем, если это кому-то надо, то он, я полагаю, вполне может отправить pull-реквест -- ну, в качестве альтернативы для libudev, с возможностью отключения при компиляции.> Есть libcap - пользуемся, нет - работаем как есть. Но, понятно, гномоводы
> не привыкли делать так, всё прибивают на свой юз-кейс...Прибивать на чужой юзкейс -- это глупость. Софт должен писаться для конкретных целей. Если софт пишется на все случаи жизни, то случается системд. Если в команде разработчиков нет того, кому мешает libcap, значит libcap не мешает. А он не мешает: там где есть ядро linux, можно потерпеть и libcap. Тем более что на libxz и libdbus уже согласились, а они ведь потолще будут в разы.
Для тех кто не понимает.
Берётся очередной одноплатник за 3 копейки с сетью и юзби, в него втыкается гпс, он же подключается к сети.
Туда натывается бсд/лiнупс и софтина, потом это ставится куда то где хорошо с приёмом.
Все счастливы.В случае с кучей зависимостей одноплатник за 3коп уже может не подойти, не говоря об всяких особенностях сборки.
> Для тех кто не понимает.
> Берётся очередной одноплатник за 3 копейки с сетью и юзби, в него
> втыкается гпс, он же подключается к сети.
> Туда натывается бсд/лiнупс и софтина, потом это ставится куда то где хорошо
> с приёмом.
> Все счастливы.
> В случае с кучей зависимостей одноплатник за 3коп уже может не подойти,
> не говоря об всяких особенностях сборки.Для тех, кто не понимает, повторяю ещё раз: там нет кучи зависимостей. Ты замучаешься искать одноплатник, который потянет linux, но при этом умрёт от dbus и libudev. При этом, libudev там уже будет стоять, иначе с использованием usb будут проблемы: юзерспейс процесс может конечно общаться с ядром напрямую, без прослоек, но какой дурак будет заниматься этим онанизмом? А dbus'ом положить одноплатник? Когда линукс работал на двух метрах памяти, dbus может и был критичен. Когда же он начал жрать память десятками мегабайт, то железка которая потянет его, потянет заодно и dbus.
А особенности сборки -- если уж взялся возиться с одноплатниками, то должен справится с кросс-сборкой из rust. Он же через llvm работает, а у llvm с этим неплохо. Вон, под AVR собирают rust-код, и ничего. А у тебя ж ARM небось, да?
гугл что-ли проплатил разработку? Или яндекс? Хотят точно знать где клиент находится, чтобы рекламу нужную втюхивать?
Мерзость эта ваша геолокация! Отключаю её всегда, если есть возможность
здесь правильно говорить о геопозиционировании, а не геолокации
А мультиплексация даты и времени с атомных часов GPS-спутников поддерживается?
> А мультиплексация даты и времени с атомных часов GPS-спутников поддерживается?Какие атомные часы? USB и сеть вносят непредсказуемые задержки. NMEA строка с координатами и временем.
По какому протоколу идет обмен GPS данными? NMEA какой? Если это NMEA/
Доступ к GPS приемнику по сети для указания своего местоположения? То есть в реальности можно вообще находится на другом конце света? Тогда это скорее утилита для скрытия своего местоположения.
Это теперь компиляция гнома требует раста? И зачем мне недоязычки в системе?
> GPSD имеет серьёзные архитектурные проблемыСписок "архитектурных проблем" выглядит скорее как список преимуществ по сравнению с хипстерскими поделками.
выглядит как socat -u /dev/ttyUSB0,b38400,raw tcp-l:8989,fork,reuseaddr + прикрутили avahi.
ЗЫ. но это не точно, документация скудна, "чукча" не растописатель.
GPSD умеет это уже несколько лет, зачем очередной велосипед?
> GPSD умеет это уже несколько лет, зачем очередной велосипед?Уточню: GPSD умеет это уже более 20 лет и делает это костыльным и неактуальным для современных систем способом.
Народ, вы вдумайтесь наконец.
GPS это получение координат и точного времени.
Это не сеть передачи данных.
Координаты всегда будут у того, кто типа "прокси".
Синхрон времени можно просто брать с этого "прокси".
Смысл проекта минус двадцать.
Идиотизм какой-то.
смысл - тут уже пример был - судно с каютами и одна GPS антенна. В каютах антенны не работают. И тянуть в каждую свою внешнюю на мачту - там воронам тогда сесть некуда будет... Продолжаем тупить и думать дальше, зачем расшаривать GPS