Разработчик ПО Linux/C/C++ (СПб)

> P.S. то, про что вы хотели спросить, обсуждается

а в каком диапазоне обсуждается? если гуй был в институте последний раз, а всё остальное время были только матриц умножения - но явно больше 3х лет и с высшим образованием?

> а в каком диапазоне обсуждается?

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

Единственное что могу сказать - фирма конкурентноспособна.

если гуй был в институте последний раз, а всё остальное время были

только матриц умножения - но явно больше 3х лет и с высшим

образованием?

Education is what survives when what has been learnt has been forgotten, right?

Если вы прекрасно числодробите, можете быстро вспомнить GUI и оперативно разобраться с новой для себя темой - это хорошо.

> фирма конкурентноспособна

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

так как зависит диапазон? от чего зависит? где границы диапазона? вопросов стало больше.

то выражение скорее про остаточные знания, чем про образование. хотя кто чем и как пользуется

пшол вон, троль.
тебя все равно не хотят.

2gunja:

Фирма конкурентноспособна на рынке труда в том смысле что может предложить достойную компенсацию за труд своим сотрудникам.

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

Многие вопросы можно обсудить на интервью.

Также хочу заметить, что вопрос компенсации является очень важным, но мы стараемся отдавать предпочтение тем кандидатам, которых в первую очередь интересует чем придётся заниматься.

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

Насколько требуется знание именно особенностей Линукса? Скажем, тот продукт, над которым я сейчас работаю, функционирует под Windows/Linux/FreeBSD, но мне до различий этих систем практически не приходится опускаться.

Кто вам нужен - скорее прикладной или скорее системный программист?

И, как минимум, нижнюю границу возможной зарплаты стоит озвучить.

Александр, добрый день.

Специализация безусловно присутствует. Если в двух словах - нам нужны люди как с системными, так и с прикладными навыками.

Такими могут быть два специалиста, но лучше чтобы это был один человек - разработчик безусловно в чём-то лучше/больше разбирающийся, но готовый, и имеющий для этого навыки, решать проблемы и на стыке, и в комплексе.

Linux - потому-что некоторые вещи системно-зависимы и сильно, и ещё, потому-что модель разработки позаимствована из этой среды.

Пример задачи, где больше востребованы системные навыки - это разработка прототипа того, что в будущем должно стать обще-корабельной системой обмена данными. Потоков информации много, и у всех свои требования к задержке и пропускной способности, и кое-где весьма суровые. Здесь нужно выжать всё по максимуму и на аппаратном, и на программном уровне.

Пример более прикладной задачи - это разработка информационной системы поддержки для людей на объектах - своего рода экспертная система с визуализацией состояния что/где происходит (состояние энергетической установки, двигателей, где пожар/поступление воды, где сработала охранная сигнализация ...), выдачей справки и для помощи в принятии решений.

Это только два примера. Реально задач намного больше. От простого engineering'а до проблем, к которым не совсем понятно как подступиться.

Везде, насколько, и где это возможно, стараемся использовать и создавать кроссплатформенные решения, но это не покрывает всего проекта.

По поводу компенсации.

Если наше объявление заинтересовало вас, я могу только ещё раз предложить описать ваши ожидания по заработной плате и другим вопросам в сопроводительном письме.

С уважением,
Кирилл

на сколько помню, то допуск к гос-тайне предполагает 15 лет невыезда.

допуск к сов секретным материалам - 5 лет невыезда и сколько-то неразглашения.

единственное что может быть - контракт на нераспространение.

Максимум что бывает нужно - 3 уровень допуска, т.е. самый «несекретный» уровень, при котором заграницу можно выезжать хоть каждый день.

Интересует возможность работы «на дому», без допуска.
У вас какой-то коммерческий проект, но ограничения накладывает первый отдел?

Еще актуально?

Работа только на дому - скорее нет, чем да. Время от времени появляются
отдельные вспомогательные или самодостаточные задачи (примеры в конце), но их
не много.

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


Проект коммерческий по заказу МО РФ. Требования к секретности не предъявляются.
3 уровень допуска нужен для того, чтобы иметь возможность пройти на
производство которое находится на территории близ-стоящего завода и на объекты,
куда поставляется система.

Ещё раз хочу повторить что это самый минимальный уровень, который практически
не влияет на выезд за границу.


P.S.

$ nslookup

lubyagin.discrete.ru

;; Got SERVFAIL reply from 195.19.225.253, trying next server
;; Got SERVFAIL reply from 195.19.225.254, trying next server
Server: 127.0.0.1
Address: 127.0.0.1#53

** server can't find lubyagin.discrete.ru: SERVFAIL


P.P.S. актуально


Привожу примеры вспомогательных или самодостаточных задач. Для нас будет только
лучше, если всё это сразу будет в upstream или будет оформлено как отдельный
открытый проект.

Если что-то интересно - стучитесь в mail.


msysgit v.s. русские имена файлов
---------------------------------

Git используется не только для исходных текстов, но и для документооборота.
Конструкторы сидят под win. Соответственно есть проблема с обработкой русских
имён файлов в msysgit которую нужно поправить:

http://code.google.com/p/msysgit/issues/detail?id=80


Подсистема конфигурации устойчивая к сбоям питания
--------------------------------------------------

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

obj = cfg.get(ckey)
cfg.put(ckey, obj)

например:

cfg.get('//rdr0/dzero')
cfg.put('//rdr0/dzero', 390.0)


В качестве backend'а для всего этого используется база данных, не SQL, а
из более простого семейства потомков Dbm.

http://en.wikipedia.org/wiki/Dbm

Мы используем не GPL'ный Berkeley DB, а LGPL'ный TDB из Samba

http://tdb.samba.org/

Всё это хорошо, тем более что TDB поддерживает транзакции и
crash-recovery, но неприятности возникают в момент, когда всё это
сталкивается с флэш-накопителями, у которых перед записью должен
обязательно быть erase большого блока.

http://lwn.net/Articles/349970/
http://ozlabs.org/~rusty/index.cgi/tech/2009-10-20.html

Соответственно встаёт вопрос о том, как действительно добиться 100% гарантий
восстановления базы после сбоя питания и не попортить остальные данные на
flash.

Сейчас в качестве накопителей мы используем Compact Flash карты. Возможно
что-то можно сделать на программном уровне (доработать TDB, fs), а что-то
только на аппаратном.

Вопрос по своему интересный и требует проработки.



LGPL Qt VNC client widget
-------------------------

Требуется разработать виджет VNC клиента для Qt ver. >= 4.5

На мой взгляд самым разумным решением будет просто доработать библиотеку
gtk-vnc для поддержки и GTK и Qt (а-ля как это сделано в webkit, poppler,
etc...).

http://live.gnome.org/gtk-vnc

Остальные библиотеки VNC клиентов которые удалось найти, либо GPL, либо
недоделанные/брошенные/плохо работающие.


distrogit: SCM для дистрибутивов
--------------------------------

Сейчас в качестве базового дистрибутива мы используем X.

По большому счёту это удобно, но со временем, X будет всё больше и больше
отставать от современного положения дел, и отдельные пакеты придётся обновлять.

Кроме того, в экспериментальных разработках на мой взгляд имеет смысл
базироваться на X+1.

Отсюда возникает следующая задача:

Нужно вне зависимости от того, что сейчас установлено на машине разработчика
(это конечно Linux, но потенциально неизвестно какой версии) иметь возможность
собрать проект в том окружении в котором он был-сдан-в-архив или просто по
выбору.

Если используются только релизы, в архив можно положить DVD с X 1.0, 2.0, и
т.д. и просто сослаться что перед сборкой нужно сделать bootstrap с такого-то
dvd и установить такие-то пакеты. Всё кроме вставить dvd можно конечно делать
автоматически,

но

Рано или поздно возникнет необходимость обновлять отдельные пакеты, и скорее
всего отслеживать изменения в X+1.

Тогда, можно было-бы регулярно архивировать репозиторий дистрибутива с нужными
пакетами, и опять же, административно говорить «возьми DVD #348» и сделай
bootstrap с него.

На мой взгляд это неудобно потому, что таких DVD будет слишком много, и всех их
будет нужно где-то систематически хранить. Если интенсивно пользоваться таким
инструментом, объём данных будет расти очень быстро + сами операции будут
выполняться очень долго, что приведёт к тому что медленным инструментом просто
не будут пользоваться.

поэтому

Есть идея использовать умение git'а эффективно жать информацию в pack'и с
помощью дельта компрессии и просто завести репозиторий с бинарными пакетами
storage-backend которого будет git.

Да, пакеты сами по себе плохо корреллируют друг-с-другом, поскольку по сути это
пожатые архивы, а на сжатых данных дельта компрессия работает плохо, но ведь
можно помочь git'у, и перед помещением пакета в базу 1) сначала его распаковать
в дерево файлов + мета информации, 2) поместить всё это в git, 3) после
извлечении из базы дерева файлов и мета информации опять всё запаковать.

В этом случае при небольших изменениях в содержимом пакетов, дельта компрессия
будет работать хорошо, что приведёт к росту базы на Δ а не линейно.
Соответственно и база будет удобоваримого размера, а не как например

http://snapshot.debian.net/du/du.png

Да, tricky part есть в том, что нужно постараться воссоздать оригинальный
пакета с точностью до бита — иначе фокус не пройдёт rpm или dpkg будут
ругаться на несовпадение контрольных сумм и подписей. Но решение здесь есть, и
смотреть нужно в сторону того как работают debdelta и rpmdelta ...

Если это реализовать должным образом, качественно, так чтобы не тормозило, со
специализированными мини серверами, которые позволят разговаривать клиентам с
базой по apt:// и yum:// протоколам, это будет интересно и Debian'у и Fedor'е и
остальным. И ещё тем, кто делает производные дистрибутивы.

Тянет на отдельный проект.

Соответственно встаёт вопрос о том, как действительно добиться 100% гарантий восстановления базы после сбоя питания и не попортить остальные данные на flash.

Сейчас в качестве накопителей мы используем Compact Flash карты. Возможно что-то можно сделать на программном уровне (доработать TDB, fs), а что-то только на аппаратном.

Вопрос по своему интересный и требует проработки.

Ну по всей видимости не стоит использовать именно CF для подобных чувствительных операций. Голый флеш-массив с прямым поблочным доступом и что-нить типа JFFS2 поверх. Но это уже геморрой чуть другого уровня, нежели просто воткнуть копеечную фшелку в штатный CFII разъем. Не факт, что он подойдёт в Вашем случае.

Требуется разработать виджет VNC клиента для Qt ver. >= 4.5

На мой взгляд самым разумным решением будет просто доработать библиотеку gtk-vnc для поддержки и GTK и Qt (а-ля как это сделано в webkit, poppler, etc...).

Поверхностный анализ внутренностей gtk-vnc оставил стойкое впечатление, то проект намертво прибит гвоздями к GTK. IMHO скорее это выльется в создание собственного виджета практически с нуля, используя при этом gtk-vnc разве что как референсную модель.

PS: Разве что есть методики рисования Qt-шны оберток поверх GTK. Но я так с ходу ничего подобного не припомню. Впрочем, никогда подобного и не искал.

Да ведь в vnc-клиенте главное не виджет, а работа с протоколом и фреймбуфером.
Если это не так, то так должно быть.

По крупному от тулкита на вскидку нужны только регионы, возможность
сблитировать регион поверхности из памяти на выводимый виджет, клавиатура/мышка
и, возможно, таймеры.

Есть например SDL_vnc, который работает с SDL'ными поверхностями (а их
совершенно не проблема привязать что к выводу в gtk что в qt), но только сам
протокольный уровень там старый, и с пол-тыка оно не захотело разговаривать с
существующим сегодня Xvnc4. Да и последнее обновление было в 2004 году.

Gtk-vnc судя по всему сделан опытными людьми, поддерживается до сих пор. Те кто
его делали, делали и серверную поддержку vnc в qemu + от туда-же судя по всему
появились и некоторые расширения VNC протокола (s/Liguori/ в rfbproto.pdf).
Плюс проект живёт.

Отсюда и сделан вывод о том, что gtk-vnc - это хорошая база.

Если база сильно прибита к gtk/glib - не вопрос. На выходе нужен lgpl виджет
клиента vnc под qt4. Только писать его с нуля, или драконить gtk-vnc/whatever,
и потом самостоятельно поддерживать, на мой взгляд не есть правильное решение.

Совмещать qt и glib'овские event loop'ы точно можно. Кажется можно и устроить
совместное рисование qt/gtk, но это на мой взгляд будет шаг не в ту сторону.
Лучше разделить на тулкито-независимое ядро + отдельные привязки к gtk и qt.


Про CF vs raw-flash + jffs2 — так-то оно так, и примерно понятно, что если
в руках mtd, как достигнуть результата.

К сожалению выбор аппаратных платформ не большой, и всё что до сих пор
используется идёт с интерфейсами CF + ide/sata.

Изменить тут что-то можно, но сложно и долго. Поэтому интересно попробовать
решить проблему на том что есть.


Кирилл

Еще актуально?

Да, актуально.