abbra: (Default)
abbra ([personal profile] abbra) wrote2010-03-14 06:59 am

Рабочее и не очень 2

Разборки с V4L2 продолжаются, но даже текущее "на коленке" добавило пять кадров в секунду для 720p, что не может не радовать.

Также ищем еще kernel developers для работы с V4L2, камерой и остальным. Вдруг обнаружились кадровые резервы со стороны отдела кадров. :)

Купил билеты, буду в Москве 25-26 марта. 25-го займемся фундаментальной медициной, а 26-го по большей мере свободно, можно расписывать.

[identity profile] cyanide-burnout.livejournal.com 2010-03-29 03:23 am (UTC)(link)
Позволю себе еще один коммент :)
Помните, мы с вами обсуждали в моей уютной ЖЖшечки проколы libconic и icd2, в тот раз я был не готов тогда их описать. Так вот:
1. Совсем не концептуально называть соединением то, что фактически является коннекшн-менеджером.
2. Уж совсем правильным было бы если метод connect возвращал указатель на контекст соединения, а не статус отправки DBUS. Все остальные методы, ориентированные на контекст соединения должны работать с ним.
3. Все-таки icd2 должен научится знать интерфейсы, отличные от модема и файфая. Сейчас из-за этого приходится делать обвязку и делать костыль вида анализа наличия хоть каких-то соединений при отлупе ConIc.
Ну дальше по обсуждаемой тут теме:
4. В модели данных icd2 нужно ввести классификатор соединения вида "Internet", "Operator services".
5. В libconic ввести метод, устанавливающий соединение по классификатору как с диалогом выбора соединения, так и с автоматическим соединением.
Собственно вот. В принципе готов завести все это на bugs, но, кмк ваши финские коллеги опять положат на это болт либо проявят агрессию.с

[identity profile] cyanide-burnout.livejournal.com 2010-03-29 10:29 am (UTC)(link)
Вы меня не услышали. Я говорю о классификаторе типа назначения, а не типа несущей. В любом случае для введения классификатора типа назначения потребуется доработка icd2.

[identity profile] silpol.livejournal.com 2010-04-07 07:01 pm (UTC)(link)
Заносите но имейте в виду -- суть излагаемого Вами в том, что операторы хотят себя дифференциировать от интернета, при этом пользуясь инфраструктурой. Беда лишь в том что ВСЕ эти спецификации -- это нужды операторов но никак не потребителей. Поэтому и выполнять их будут в рамках требуемого потребителями.

[identity profile] cyanide-burnout.livejournal.com 2010-04-07 07:11 pm (UTC)(link)
Руки в близжайшее время дойдут - обязательно занесу. Только это не просто "нужды операторов", это уже принятые стандарты. В том чисте при участии вашей альма-матер :)
Ну и наконец - вся это чехорда с IMS и SIP-ом на терминалах связана не только с необходимостью реализации услуг в IP-домене, но и повышение юзабельности. В схеме с CSCF-ом в принципе необходимость настройки IP-сервисов отпадет. Чего только стоит одна настройка MMS.

[identity profile] silpol.livejournal.com 2010-04-08 08:42 am (UTC)(link)
я "как бы в курсе" - с 98го по 2003 работал в той части нашего дурдомчика, которая "собрала на коленке" и GGSN, и 3G-SGSN, и многое другое, и даже в 2003 Эрики были как-бы-слегка-позади, и все это при том что стандартов тогда не было и мы сами их писали (не сами, разумеется, там и остальные OEMы были, но наши люди драйвили стандарты)

с тех пор, разумеется, много воды утекло, изменились расклады на рынке, но не изменилось главное -- телко операторы все те же грязные жадные свиньи, которые гребут ТОЛЬКО под себя, и все что делается на network side -- делается на 99.999% для них. К сожалению, это оставляет многие желания реальных пользователей "за бортом" (потому что желания эти идут поперек доходных статей операторов). Такое поведение создало своеобразное "водохранилище неудовлетворенных желаний", поэтому если нам интересно "заработать неприличное число бабла" на ТЕРМИНАЛАХ, то черпать его надо аккурат оттуда, а с операторами надо вежливо и сдержанно держать их во 2-ом приоритете, хватит, накомрили их уже. Если при этом N-ная часть их сдохнет, а остальные превратятся в utility business model - будет только лучше для конЕчных людей. Т.е. нас с вами.