Пару месяцев назад возникла надобность разбираться с форматом пакетов данных, передаваемых по радио. В ряде статей и дискуссий на эту тему попадались упоминания софтины Universal Radio Hacker, которую там очень сильно хвалили. Скачал, попробовал — в целом оно, конечно, всяко удобнее ручного декодирования, но ряд функций сделан достаточно странно. Вскоре заметил насколько глюков, по наиболее явным из которых запостил отчет на GitHub.
Ответы со стороны одного из "членов группы поддержки" очень сильно смахивают на типичную позицию современных блогеров: "мой блог, что хочу, то и пишу, и мне насрать на то, что вы все об этом думаете". В принципе, позиция вполне понятная, но для чего, при таком отношении, размещать проект на Гитхабе, где дискуссии и отчеты об ошибках в обязательном порядке привязаны к репозиторию?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ответы со стороны одного из "членов группы поддержки" очень сильно смахивают на типичную позицию современных блогеров: "мой блог, что хочу, то и пишу, и мне насрать на то, что вы все об этом думаете". В принципе, позиция вполне понятная, но для чего, при таком отношении, размещать проект на Гитхабе, где дискуссии и отчеты об ошибках в обязательном порядке привязаны к репозиторию?
Бывает по-разному: если кто-то присылает реально важный для меня баг, то я исправляю. Иначе говорю, мол, исходники открыты, хотите — исправляйте. Ну или за деньги я сам. Если я выкладываю что-то в опенсорс, то я не обязан никому и ничего кроме самих исходников в соответствии с выбранной лицензией.
Re[2]: В поддержке опенсорса такое нынче нормально?
В данном случае до обсуждения исправлений даже не дошло. В моем отчете была описана как очевидная неправильность (в первой части), так и особенность, которую можно трактовать и как баг, и как фичу. Человек прочитал мой отчет по диагонали, полностью проигнорировал первую часть, сразу закрыл кейс, как не имеющий значения, а во второй части ухватился за какие-то близкие его пониманию тонкости, о которых и трындел упорно вплоть до сегодняшнего дня, не обращая никакого внимания на мои настойчивые попытки перевести его внимание на очевидный косяк. Именно это меня и удивило.
Как сегодня выяснилось, он даже не пытался ни открыть файл с исходным сигналом, который я приложил, ни соотнести друг с другом образцы данных, которые я привел в отчете. Тупо закрыл кейс и слал отписки, пытаясь убедить меня в том, что я сам дурак и ничего не понимаю. И даже после того, как я фактически загнал его в угол демонстрацией видео, выкатил скриншот в стиле "у меня такая же нога, но не болит".
На мой взгляд, тут или трусы, или крестик: выложили проект на гитхабе — проверяйте отчеты об ошибках хотя бы в общих чертах, на правдоподобность, и мало-мальски правдоподобные оставляйте открытыми. У кого-то когда-то руки дойдут — исправят. А закрывать отчет и посылать автора лишь потому, что лично тебе такой ситуации не встречалось — явное жлобство в стиле компаний, поставляющих софт госконторам в расчете на то, что съедят любое дерьмо, лишь бы договор подписали.
Re[3]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В данном случае до обсуждения исправлений даже не дошло.
Попробуй открыть новый тикет, в котором постарайся исправить ошибки предыдущего. Напиши в чем отличие от предыдущего обсуждения, бей строго в одну точку — в единственную проблему, по которой скорее всего не будет спорных моментов.
Здравствуйте, Буравчик, Вы писали:
Б>Попробуй открыть новый тикет
Уже переоткрыли, главный разработчик подключился. Правда, он пол линуксом таки не смог воспроизвести косяк, но прогресс налицо. У меня этот косяк почему-то тоже перестал надежно воспроизводиться. На днях попробую локализовать условия.
Re[3]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>На мой взгляд, тут или трусы, или крестик: выложили проект на гитхабе — проверяйте отчеты об ошибках хотя бы в общих чертах, на правдоподобность, и мало-мальски правдоподобные оставляйте открытыми. У кого-то когда-то руки дойдут — исправят. А закрывать отчет и посылать автора лишь потому, что лично тебе такой ситуации не встречалось — явное жлобство в стиле компаний, поставляющих софт госконторам в расчете на то, что съедят любое дерьмо, лишь бы договор подписали.
Но у тебя нет с ними никакого договора. "Как заплачено, так и зафигачено."
Re[4]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Человек прочитал мой отчет по диагонали, полностью проигнорировал первую часть, сразу закрыл кейс, как не имеющий значения, а во второй части ухватился за какие-то близкие его пониманию тонкости
Вывод: не подавать в одном отчете больше одной проблемы за один раз. Иначе у принимающей стороны может случится когнитивный диссонанс.
Re[4]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Aquilaware, Вы писали:
A>не подавать в одном отчете больше одной проблемы за один раз. Иначе у принимающей стороны может случится когнитивный диссонанс.
Там, судя по всему, не диссонанс случился. Больше похоже на то, что у человека, который взялся отвечать, изначально стояла задача побыстрее закрыть любой отчет, который не интересен лично ему. Он бегло просмотрел текст и, как только увидел там, на что он мог бы хоть как-то возразить, принялся вдохновенно нести совершенно левую чепуху.
Если он так вел себя умышленно, чтоб упросить себе работу, это еще можно понять. Если же он реально "когнитивно залип" только на том, что опознал, как "близкое", то грустно от такого уровня в поддержке неплохого, по сути, продукта.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Пару месяцев назад возникла надобность разбираться с форматом пакетов данных, передаваемых по радио. В ряде статей и дискуссий на эту тему попадались упоминания софтины Universal Radio Hacker, которую там очень сильно хвалили. Скачал, попробовал — в целом оно, конечно, всяко удобнее ручного декодирования, но ряд функций сделан достаточно странно. Вскоре заметил насколько глюков, по наиболее явным из которых запостил отчет на GitHub. ЕМ>Ответы со стороны одного из "членов группы поддержки" очень сильно смахивают на типичную позицию современных блогеров: "мой блог, что хочу, то и пишу, и мне насрать на то, что вы все об этом думаете". В принципе, позиция вполне понятная, но для чего, при таком отношении, размещать проект на Гитхабе, где дискуссии и отчеты об ошибках в обязательном порядке привязаны к репозиторию?
Странный багрепорт, шаг "Create a project" в котором не соответствуют видео, при этом проект аттачить всё равно не стал. Хм.
1000111010001110100011101000100010001110100011101000111010001110100010001000100010001000111011101 можно рассматривать как
Выглядит так, что hex view только гарантирует нормальный вид для полных пакетов, а с неполными косяк — вот это и надо было репортить, по-моему. И точно безо всякого "Unfortunately, you don't understand me at all", типа "перечитай, дурак" (может, ты и прав, но друзей так не заведёшь).
Потом это "I'm afraid you misunderstood the problem. If fact, I reported two different problems, one for the Interpretation tab, and another for the Analysis one" — 2 проблемы, значит, 2 тикета. И вторая проблема так то вряд ли проблема вообще, но хотя бы обсуждение второго бага не мусорило обсуждение первого. бага).
Re[2]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, aik, Вы писали:
aik>шаг "Create a project"
Не Create, а Open. Про это я действительно поначалу забыл. Если б оппонент задавал уточняющие вопросы — вспомнил бы, конечно. Но оппонент меня, как видно, сразу стал откровенно посылать.
aik>1000111010001110100011101000100010001110100011101000111010001110100010001000100010001000111011101 можно рассматривать как aik>1000 1110 1000 1110 1000 1110 1000 1000 1000 1110 1000 1110 1000 1110 1000 1110 1000 1000 1000 1000 1000 1000 1110 1110 1 (88ee в конце) aik>или aik>1 0001 1101 0001 1101 0001 1101 0001 0001 0001 1101 0001 1101 0001 1101 0001 1101 0001 0001 0001 0001 0001 0001 1101 1101 (11dd в конце)
Нельзя. В обработке сигналов, передаваемых в реальном времени, принято рассматривать последовательность импульсов так, как она поступила от источника. Дополнение нулями справа (то есть — позже по времени) — нормальное явление и применяется повсеместно, дополнение чем угодно слева — по определению бессмысленное действие, потому не применяется.
aik>Выглядит так, что hex view только гарантирует нормальный вид для полных пакетов
Hex view показывает не "пакеты" (на этом этапе про них еще ничего неизвестно), а "нибблы" — шестнадцатеричные цифры. По этому вопросу есть устоявшееся соглашение — неполные нибблы дополняются нулями справа. Поэтому одинокая единица в конце должна отображаться, как "8", если не задано каких-то особых правил.
aik>И точно безо всякого "Unfortunately, you don't understand me at all", типа "перечитай, дурак" (может, ты и прав, но друзей так не заведёшь).
А мне и не нужно с ним дружить. Моей задачей было предоставить информацию, которую мне довелось обнаружить. Если б он сразу сказал что-то вроде "спасибо, но мне на это насрать, иди на хер", это было бы грубо, но честно. А он стал нести совершенно левую чушь, держа меня за дурака, который умеет только мышкой возить. На это нужно было указать, чтоб не увлекался.
aik>2 проблемы, значит, 2 тикета.
Это да, переоценил я способности тамошнего восприятия. Мерил-то по себе — мне иногда в одном письме и про три-четыре разных проблемы пишут, и я в них не путаюсь, лишний раз перечитать гораздо быстрее, чем писать ответ, так что экономить не на чем. Да и проблемы схожие, в одной сфере — обе в неправильном отображении вида Hex.
Re[3]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Евгений Музыченко, Вы писали:
aik>>шаг "Create a project" ЕМ>Не Create, а Open. Про это я действительно поначалу забыл. Если б оппонент задавал уточняющие вопросы — вспомнил бы, конечно. Но оппонент меня, как видно, сразу стал откровенно посылать.
Это не "посылать" ни разу. Посылать — это когда тикет закрывается с комментарием "заполните все, вообще все 500 полей формы багрепорта".
ЕМ>Нельзя. В обработке сигналов, передаваемых в реальном времени, принято рассматривать последовательность импульсов так, как она поступила от источника. Дополнение нулями справа (то есть — позже по времени) — нормальное явление и применяется повсеместно, дополнение чем угодно слева — по определению бессмысленное действие, потому не применяется.
Да пофиг. Я просто (не глядя в код) думаю они кусками по 64 бита обрабатывают внутри и разный код по разному нарезает эти потоки битов.
aik>>И точно безо всякого "Unfortunately, you don't understand me at all", типа "перечитай, дурак" (может, ты и прав, но друзей так не заведёшь). ЕМ>А мне и не нужно с ним дружить.
Смысл репорта вообще в чём? Тебе нужен фикс или ткнуть их носом в багу?
EM>Моей задачей было предоставить информацию, которую мне довелось обнаружить.
Ты даже сам уверенно воспроизвести не можешь, мне ни разу не удалось. В чём ценность этой информации для них? Сразу ясно — дохлый кейс.
ЕМ>Если б он сразу сказал что-то вроде "спасибо, но мне на это насрать, иди на хер", это было бы грубо, но честно. А он стал нести совершенно левую чушь, держа меня за дурака, который умеет только мышкой возить. На это нужно было указать, чтоб не увлекался.
Нет, не нужно на это указывать. Люди пишут софтину забесплатно, в свободное время. Поэтому если хочется реальной помощи — то багрепорты должны быть короткие, чёткие, количество шагов минимальное. Прикинь — чувак пришёл с работы, поужинал и пошёл проверить баги проектика — хочется сразу понимать суть бага. В идеале — шли патчи/хаки (код же есть) или форкни для себя и чини.
aik>>2 проблемы, значит, 2 тикета. ЕМ>Это да, переоценил я способности тамошнего восприятия.
Это не "тамошнее", это вообще нормально по 1 тикету на 1 баг. Ну и отсутствие оплаты освобождает от обязательств чинить, конечно.
ЕМ>Мерил-то по себе — мне иногда в одном письме и про три-четыре разных проблемы пишут, и я в них не путаюсь, лишний раз перечитать гораздо быстрее, чем писать ответ, так что экономить не на чем. Да и проблемы схожие, в одной сфере — обе в неправильном отображении вида Hex.
В половине случаев мои корреспонденты отвечают только на первый вопрос. Поэтому я стал дробить емейлы/тикеты, но если надо непременно несколько вопросов и в одной куче (типа если чиним баг1 вот так — то вылезает баг2) — то я их явно нумерую. Твой репорт — 5 пунктов и 2 скриншота, даже не потрудился кружочками обвести проблемные цифры.
А ещё там деревьев сообщений нет, и квотинг молодёжныйнеудобный.
Re[4]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, aik, Вы писали:
aik>Посылать — это когда тикет закрывается с комментарием "заполните все, вообще все 500 полей формы багрепорта".
Если тикет закрывается без оценки по сути — какая разница, что при этом написано в комментарии?
aik>думаю они кусками по 64 бита обрабатывают внутри
Э-э-э... Что там, по-Вашему, можно "обрабатывать по 64 бита", и для чего?
aik>Смысл репорта вообще в чём? Тебе нужен фикс или ткнуть их носом в багу?
Второе. Сперва хотел просто обратить внимание, но после столь откровенного посыла пришлось уже тыкать носом. А делать ли фикс — это их дело.
aik>Ты даже сам уверенно воспроизвести не можешь
С чего вдруг? Как я, по-Вашему, видео сделал?
До этого оно у меня почти два месяца уверенно воспроизводилось. Но как-то не догадался при каждом запуске записывать видео и снимать дампы.
aik>В чём ценность этой информации для них?
В информации. Которой у них, судя по всему, до меня не было.
aik>Сразу ясно — дохлый кейс.
Ну вот и ответ на вопрос, вынесенный в заголовок темы. У меня к багрепортам отношение несколько иное.
aik>отсутствие оплаты освобождает от обязательств чинить, конечно.
Где я что-то говорил об "обязанности чинить"?
Re[5]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Евгений Музыченко, Вы писали:
aik>>Смысл репорта вообще в чём? Тебе нужен фикс или ткнуть их носом в багу? ЕМ>Второе. Сперва хотел просто обратить внимание, но после столь откровенного посыла пришлось уже тыкать носом. А делать ли фикс — это их дело.
А, это было неочевидно. Я создаю тикеты чтоб сказали как обойти проблему или почему оно так.
aik>>Ты даже сам уверенно воспроизвести не можешь ЕМ>С чего вдруг?
"BTW, I found that the issue is not 100% reproducible".
ЕМ>До этого оно у меня почти два месяца уверенно воспроизводилось. Но как-то не догадался при каждом запуске записывать видео и снимать дампы. aik>>В чём ценность этой информации для них? ЕМ>В информации. Которой у них, судя по всему, до меня не было.
Что с кривым конфигом — кривой результат? А то они не в курсе.
aik>>Сразу ясно — дохлый кейс. ЕМ>Ну вот и ответ на вопрос, вынесенный в заголовок темы. У меня к багрепортам отношение несколько иное.
По репорту не очень заметно. После слов "only by adding the signal to a open project" у меня бы рука тянулась приаттачить проект.
Re[6]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, aik, Вы писали:
aik>>>Ты даже сам уверенно воспроизвести не можешь ЕМ>>С чего вдруг?
aik>"BTW, I found that the issue is not 100% reproducible".
Ну вот как-то получилось так, что почти два месяца я это видел при каждом запуске, а потом оно резко пропало на том же файле проекта. Софтина перезаписывает файл проекта при каждом запуске — видать, что-то в нем изменила, но я ж не вел истории версий.
aik>Что с кривым конфигом — кривой результат? А то они не в курсе.
Даже если б конфиг был двоичным, подобное влияние конфига на преобразование данных при отображении заставляет сильно подозревать серьезные внутренние косяки, вроде порчи случайных областей памяти, висячих указателей, неинициализированных переменных и т.п. А уж когда конфиг в XML — и подавно. Пытаться замести такое под ковер может только откровенный вредитель, отчего я сразу и напрягся. Я очень невысокого мнения о профессиональной квалификации программистов, пытающихся игнорировать подобные эффекты лишь по причине их чисто внешней несерьезности.
aik>После слов "only by adding the signal to a open project" у меня бы рука тянулась приаттачить проект.
Если б подобный отчет получил я по своему софту, у меня б рука прежде всего потянулась проверить код, который вообще никак, никаким боком, не должен зависеть от проекта. Если б у меня не возникло никаких претензий к этому коду, то я сам бы попросил приаттачить проект, поскольку наличие в моем коде подобных мин замедленного действия невыгодно прежде всего мне самому. Но ребята, судя по всему, не сделали ни того, ни другого, и это говорит о том, что они либо не понимают, насколько глубоко у них может быть закопан баг, либо понимают, но им насрать, и их задача — чтоб просто "как-то работало". Но явно они этого никак не показывают.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ответы со стороны одного из "членов группы поддержки" очень сильно смахивают на типичную позицию современных блогеров: "мой блог, что хочу, то и пишу, и мне насрать на то, что вы все об этом думаете". В принципе, позиция вполне понятная, но для чего, при таком отношении, размещать проект на Гитхабе, где дискуссии и отчеты об ошибках в обязательном порядке привязаны к репозиторию?
Не вижу такой позиции в ответах с их стороны. Вижу а) непонимание сути проблемы, из-за несколько размытого изначального репорта.
Эффективнее всего писать в ишшуе об одной изолированной проблеме. В стиле "делаю 1, 2, 3. Ожидаю получить 4, получаю 5. Окружение — такое-то, исходные данные приложены".
б) у них не получается воспроизвести багу.
Это, судя по всему, от некоторого красноглазия — люди будут сидеть на системе, которая не умеет воспроизводить видео, но поставить проклятую винду даже в виртуалке для воспроизведения они брезгуют.
Особого нежелания чинить у них нет — просто парни не очень верят в то, что проблема существует.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Sinclair, Вы писали:
S>Вижу а) непонимание сути проблемы
Которое старательно замаскировано имитацией понимания совершенно другой.
S>б) у них не получается воспроизвести багу.
Так они сперва даже проверить не пытались — не то, чтоб воспроизвести. Если б с моей стороны были только слова, их вполне можно было бы понять. Но я ж с самого начала привел скриншоты, на которых сразу видно, что преобразование в Hex выполняется ошибочно.
S>Это, судя по всему, от некоторого красноглазия — люди будут сидеть на системе, которая не умеет воспроизводить видео
Изображений тоже не воспроизводит?
S>парни не очень верят в то, что проблема существует.
И это очень ярко характеризует их квалификацию, как программистов.
Re[4]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Aquilaware, Вы писали:
A>Вывод: не подавать в одном отчете больше одной проблемы за один раз. Иначе у принимающей стороны может случится когнитивный диссонанс.
Это причем никак не связано с опенсорсом. Я имел несколько случаев общения с платной поддержкой совершенно коммерческих продуктов. Вот где феерия! Это прямо коррида, как у Паниковского с гусями.
Та сторона напрочь не желает ничего читать и разбираться, предпочитая фонтанировать идиотскими предположениями про то, что может быть я пользуюсь не тем браузером, или что нужно обновить винду (это когда я им написал, что их API не соответствует спецификаации, и сразу приложил реквест и респонс). Или требование "записать видео с репродакшном" (ну да, ну да, вызовы REST API через их библиотеку особенно удачно выходят на видео, и без видео никак-никак невозможно понять, что же у меня сломалось). Мне даже замечание делали за неэтичное общение, потому что я не удержался и написал в письме очередному такому дебилу, чтобы он позвал кого-то из взрослых, раз сам не умеет читать логи.
Это всё потому, что у них две метрики: скорость ответа и удовлетворённость клиента. Вторая мало колеблется — в западном мире не принято объективно оценивать сервис. А первая от вдумчивости только страдает. Поэтому большинство пишут любую чушь, похожую на ответ, и переходят к следующему тикету. И стараются отвечать что-то типа "а, наверное это что-то на вашей стороне сломано".
А коррида — собственно в том, чтобы предугадать, под каким предлогом они завернут тикет в следующий раз, и сразу писать так, чтобы они не смогли этого сделать. Орать на них смысла никакого нет — это не они такие, это система такая. Вот загнать их в угол железобетонными доказательствами того, что их софт косячит — это да, искусство! Добился эскалации в 3rdLine — считай, победил. Я потом им и видео стал прикладывать — это дешевле, чем объяснять, что трассировка REST эффективно описывается в тексте. Объяснения всего лишь приводят к дополнительному раунду инструкций "как установить screen recorder application".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: В поддержке опенсорса такое нынче нормально?
Здравствуйте, Sinclair, Вы писали:
S>Это причем никак не связано с опенсорсом. Я имел несколько случаев общения с платной поддержкой совершенно коммерческих продуктов.
С коммерческими проще понять — в поддержке сидят, как правило, нанятые сотрудники, которым судьба софта и проблемы у разработчиков по барабану. Но тех проще привести в чувство жалобами начальству. А опенсорсники вроде как занимаются поддержкой сами, и вроде как должны быть заинтересованы в любой информации, способной привести к ликвидации явных косяков в коде.
S>требование "записать видео с репродакшном" (ну да, ну да, вызовы REST API через их библиотеку особенно удачно выходят на видео
Я этого долгое время тоже не понимал, потом кто-то объяснил, что во многих конторах это прям часть регламента. Тупо потому, что 80% обращений выглядят в стиле "у меня ничего не работает, шозанах, я вам деньги заплатил, сделайте, чтоб работало". Чтоб предусмотреть отдельный путь для 20% вменяемых, нужно относительно разумное планирование поддержки, а с этим тоже проблемы.
Re[3]: В поддержке опенсорса такое нынче нормально?
ЕМ>Нельзя. В обработке сигналов, передаваемых в реальном времени, принято рассматривать последовательность импульсов так, как она поступила от источника. Дополнение нулями справа (то есть — позже по времени) — нормальное явление и применяется повсеместно, дополнение чем угодно слева — по определению бессмысленное действие, потому не применяется.
В блутусе например биты в канал лезут от младшего к старшему и более поздние биты там — левые. Так что нет никакого "принято" в этом вопросе.
В принципе, позиция вполне понятная, но для чего, при таком отношении, размещать проект на Гитхабе, где дискуссии и отчеты об ошибках в обязательном порядке привязаны к репозиторию?
