Автор Тема: Обсуждение и предложения по реализации базы данных проб оборудования  (Прочитано 47009 раз)

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 550
Цитата: ASte от Сегодня в 19:06:30

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

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

Навязывать не нужно. Нужно, чтобы добровольно, и с песнями :-)
« Последнее редактирование: 14.11.2017 22:41:53 от ASte »

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 550
Цитата: ASte от Сегодня в 19:06:30

    ИМХО только сбор/упаковку/отправку пробы. Остальное нужно (опять таки ИМХО) реализовывать на стороне сервера в виде стандартного web-приложения и работать все должно через  браузер. 

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

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 550
Я категорически против подобных приёмов. Нельзя ничего людям навязывать (это уже не добровольная совместная деятельность получается), вместо этого лучше сделать так, чтобы люди сами смогли оценить потребность в этом и только после этого со всей осознанностью слали пробы и/или как-либо ещё способствовали распространению данного инструмента среди своих друзей, знакомых, родственников, которые также пользуются альт линуксом.
Люди не оценят пока не будет наполнена база. Пока они сами на наполненной базе не увидят для себя пользы им будет просто и банально лень.
С другой стороны - для бесплатных стартеркитов и simply отправку пробы можно просто включить в лицензионное соглашение. Согласен с лицензионным соглашением - устанавливаешь дистрибутив и отправляешь пробу автоматически при установке.  Не согласен - собираешь себе дистрибутив сам или пользуешься Кометой. 

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 999
Тогда там так и будет добавляться по десятку проб в месяц.
В Росе почему-то шлют больше
Потому как те кто был с форума/клуба заинтересован, уже отправили. Ну кто-то еще прочитает и отправит... Но их слишком мало.. Без продвижения со стороны авторов дистрибутивов и добровольно-принудительной отправки проб при установке (или при первой загрузке в графику например) сервис никогда не наберет достаточной статистики (количества проб) чтобы стать интересным для пользователя.
и никакого принуждения к отправке там нет и в помине. Тем не менее, набрано приличное количество заливок и само количество проб, которое продолжает расти.
С другой стороны, если при каждой установке например simply будет отправляться проба (если только пользователь не откажется сам, но для этого нужно еще кнопочку нажать будет, и может быть не одну), то уже какая-то полезная статистика наверное за полгодика наберется и тогда сервис уже видится перспективным и повозиться с проектом будет иметь определенный смысл.
Об этом я писал в части статуса сервиса. По сути, статус сервиса ещё и гарантирует, что пакет будет как минимум в Сизифе, а, значит, может быть и в регулярных сборках, про бранчи пока не говорим потому как рано. А статистика может быть разная востребована - вон в Росе процентовка того или иного производителя железа от общего количества интересует и диаграмма этого на главной странице. Вообще говоря, статистика это отдельная тема и нужна она может быть в совершенно неожиданных ракурсах, для различных исследований, оценок к примеру и т.п.
Соответственно, какой тогда смысл тратить на него время?
Саморазвитие. Вы наверное думаете, что я программист, но это ошибка. Мне просто интересно проектирование и реализация и это, если хотите, вместо игры в шашки или чего-то подобного. Каждый качает мозг так, как хочет - мне вот так качать интересно, я ведь чем-либо подобным вообще говоря не занимался никогда. Плюс к тому видно, что потребность есть (то и дело возникают реплики на эту тему, что иметь базу было бы хорошо и т.д.), но она может быть не четко выражена словами (для чего), поэтому и не совсем понятно целеполагание в отношении задач, которые сервис мог решать (так то я эти задачи тут где-то в теме уже перечислял, но они может быть не так актуальны или, наоборот, слишком специфические). Но что-то вроде такой себе социальной сети вполне можно было бы сделать на базе этого сервиса. Да, да. Там имеются возможности и для коммуникации (это как бы бэкграунд того сайта, что на поверхности виден): как минимум для обмена сообщениями (пока чисто умозрительно по оценке заложенного функционала и решений), ведь шифрование и транспорт уже имеются, при этом канал может быть даже незащищенным. Осталось бы только исправить все корявости, что свойственны раннему прототипу и можно было реально пользоваться. Скажете, что есть телеграм и прочее. Но, данный клиент мог бы идти по умолчанию в дистрибутивах, а значит и сервис, который он предоставляет, уже был бы доступен сразу после установки (или даже в лайв режиме). Обращение в техподдержку тоже можно было бы делать через сервис (попутно ещё и пробу оборудования для нужд техподдержки слать). Другими словами, кейсов много разных можно перечислить и решить мх, но мало рук и программерского опыта. И на одном энтузиазме в одиночку далеко не уедешь.

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 999
Это не дилемма. Просто работать с этим сервисом через консоль никто не будет.
Оно может понадобиться только в случае автоматической отправки пробы например при установке дистрибутива (см. мое предыдущее письмо) либо при какой-то гипотетической автоматизированной обработке проб.
Если у тебя 80x25 и нет графики, то получать информацию с сервиса тоже возможно и hcl-get как раз тому подтверждение как демонстратор технологии. К тому же кому-то может быть привычнее открыть терминал и набрать команду, чем запускать браузер и там чего-то набирать (инструменты работы они ведь разные бывают).
Люди не оценят пока не будет наполнена база. Пока они сами на наполненной базе не увидят для себя пользы им будет просто и банально лень.
Люди не оценят, пока не будет наполнена база. Люди не наполнят базу, пока не оценят. Надо разорвать сначала замкнутый круг, но
С другой стороны - для бесплатных стартеркитов и simply отправку пробы можно просто включить в лицензионное соглашение. Согласен с лицензионным соглашением - устанавливаешь дистрибутив и отправляешь пробу автоматически при установке.  Не согласен - собираешь себе дистрибутив сам или пользуешься Кометой. 
только в Комету можно включить как в клубный продукт. Всё остальное это официальные репозитории и платформы, которые на ресурсах ООО хостятся и туда проход только по билетам (об этом я ранее уже писал и этот вариант пока не проходит, поэтому надо смотреть на реальные пути развития сервиса). Другими словами, во все официальное можно включить только если клиент будет в репозиториях, а сервис будет на ресурсах ООО и о нём можно будет без всякого опасения упоминать, т.к. код будет доступен и возможно будет сервис сопровождать даже без меня силами других людей, но этого пока не случилось, поскольку ответа из ООО на эту тему нет.

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 550
ИМХО пока со стороны ООО не будет интереса я пессимистически смотрю на перспективы этого сервиса.
С другой стороны имеет смысл выяснить (у представителей ООО) что именно могло-бы быть интересно ООО и именно это им попробовать предложить. 
Если у тебя 80x25 и нет графики, то получать информацию с сервиса тоже возможно и hcl-get как раз тому подтверждение как демонстратор технологии. К тому же кому-то может быть привычнее открыть терминал и набрать команду, чем запускать браузер и там чего-то набирать (инструменты работы они ведь разные бывают).
lynx или wget или curl.

только в Комету можно включить как в клубный продукт
Пользователей клубных продуктов по сравнению с пользователями того-же simply раз-два и обчёлся.
« Последнее редактирование: 14.11.2017 23:14:49 от ASte »

Оффлайн tema

  • alt linux team
  • ***
  • Сообщений: 2 073
    • Email
только в Комету можно включить как в клубный продукт.
Я как раз думал об этом. И уже внёс в список пакетов, из которых собирается установочный образ. Но это просто программа будет уже в дистрибутиве. Никакой автоматической отправки не будет. Как вариант, могу предложить создать на вновь установленной системе на рабочем столе текстовый файл и скрипт. В текстовом файле предложить отправить пробу своего оборудования, кликнув на скрипт.

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 999
lynx или wget или curl.
Писать больше (т.к. нужны дополнительные команды на вычленение запрошенных данных), а операторы консоли как правило предпочитают чем короче тем лучше, поэтому вариант с клиентом
1) короче
2) выдает только запрошенные данные без ненужного оформления веб-страницы и не требует дополнительных манипуляций для извлечения запрошенных данных
При этом, конечно, можно просто не обращать внимания на эти теги и листать в низ (иногда, кстати, и это не вариант, т.к. теги получаются как бы разбивают запрошенные данные на части), но согласитесь, что гораздо лучше получить вывод лишь запрошенного без всего остального, что для консоли лишнее
Я как раз думал об этом. И уже внёс в список пакетов, из которых собирается установочный образ. Но это просто программа будет уже в дистрибутиве. Никакой автоматической отправки не будет. Как вариант, могу предложить создать на вновь установленной системе на рабочем столе текстовый файл и скрипт. В текстовом файле предложить отправить пробу своего оборудования, кликнув на скрипт.
Текстовый файл на правах чего-то вроде документации сделать, наверное, можно было бы (при этом перед тем, как добавлять подобный файл, желательно подумать и описать в нём, чем же будет полезна отправка пробы, чтобы человек не просто тупо делал, а понимал, для чего он это делает).
А вот про скрипт не уверен: как через него будет работать функционал сбора не тестировал. Поэтому всяко лучше ручками в консоль команду вставить и нажать на ентер. Был бы графический инструмент - подобных вопросов бы не возникало (но его нет, т.к. нет желающих его написать).

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 550
Цитата: ASte от Вчера в 23:12:20

    lynx или wget или curl.

Писать больше (т.к. нужны дополнительные команды на вычленение запрошенных данных), а операторы консоли как правило предпочитают чем короче тем лучше, поэтому вариант с клиентом
1) короче
2) выдает только запрошенные данные без ненужного оформления веб-страницы и не требует дополнительных
1. лечится alias-м
2. лечится на сервере - сервер выдает нужный формат в зависимости от http-заголовка Conteny-Type запроса.


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

Никакой автоматической отправки не будет.
ИМХО без автоматической отправки безперспективно. У пользователя должна быть возможность отказаться, но для этого он должен:
а) сначала прочитать (или хотя-бы промотать в окошке) текст, в котором описывается что это такое и для чего нужно.
б)ручками снять чекбокс, "отправить пробу" который установлен по умолчанию и становится доступным для изменения только после пролистывания текста.

Т.е. пользователь должен совершить некие телодвижения для того чтобы отказаться, а не для того чтобы отправить. Только так человеческая лень станет союзником в деле собирания проб а не противником.

« Последнее редактирование: 15.11.2017 08:39:12 от ASte »

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 999
1. лечится alias-м
Сначала надо этот alias придумать, а читать доки по "протоколу" обмена будет не каждый.
2. лечится на сервере - сервер выдает нужный формат в зависимости от http-заголовка Conteny-Type запроса.
Проще сказать, чем сделать. Тогда будет два разных приложения - один для веб, второй для кейсов, когда браузера нет. В любом случае унификации не будет, что капитально увеличит количество кода и как следствие время на его создание и сопровождение. Поверьте, прежде чем что-то вообще делать, я больше месяца все взвешивал, разные гипотетические кейсы с возможностями и пришёл к тому, что есть сейчас (при этом бэкграундом также остается полный формат запроса, в зависимости от первого звена которого определяется, к какой именно базе относится запрос; другими словами, не зная бэкграунда, вы даёте советы для других случаев, которые в этом конкретном случае не подходят: увеличивают количество кода и трудозатрат в целом, усложняют без особой на то необходимости весь проект). Протокол обмена, если так можно его назвать, расширяемый достаточно и гибкий (все зависит лишь от тех представлений, что хотелось бы реализовать). Лично моё мнение, что в большей степени существование сервиса определяется потребностями в нём. Нужен кейс, который бы сделал его востребованным (причем не так важно, с какой стороны будет интерес: ООО или просто люди), тогда все остальные вопросы отпадут сами собой и можно будет отталкиваясь от потребностей расширять функционал сервиса.

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 550
Сначала надо этот alias придумать, а читать доки по "протоколу" обмена будет не каждый.
С учетом того что это непонятно кому нужно и никто явно не заявил заинтересованности в этом то можно смело на такую "сложность" забить на первом этапе.
Проще сказать, чем сделать. Тогда будет два разных приложения - один для веб, второй для кейсов, когда браузера нет. В любом случае унификации не будет, что капитально увеличит количество кода и как следствие время на его создание и сопровождение.
Зачем два разных приложения?  Если сервер правильно написан и спроектирован, то разница будет только в методе, который отвечает за оформление ответа. Проще сопровождать и обновлять  сервер проще и быстрее чем клиентов. Как минимум изменения доступны сразу после внесения их в серверный код и не нужно ждать пока обновленная версия клиента окажется в репозитории, пока пользователи обновятся и т.д.

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

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 999
Т.е. пользователь должен совершить некие телодвижения для того чтобы отказаться, а не для того чтобы отправить. Только так человеческая лень станет союзником в деле собирания проб а не противником.
Давайте так. Это уже к целеполаганию относится.
Вы предлагаете собирать пробы для цели, которую обозначили в первом посте (поиск по железу и что о нём пишут люди). Я же постоянно акцентирую внимание на том, что сервис это по сути своей социальная сеть (с возможностью добровольного вхождения, т.е. регистрация это и есть отправка пробы и именно поэтому не должно быть никакого даже намёка на навязывание, но должна быть информационная работа по донесению этой информации и её осознанию каждым потенциальным пользователем, если уж мы идём от противного, т.е. от функционирования на ресурсах ООО), функционал которой обсуждаем и это вообще говоря сделать можно.

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 8 999
Зачем два разных приложения?  Если сервер правильно написан и спроектирован, то разница будет только в методе, который отвечает за оформление ответа. Проще сопровождать и обновлять  сервер проще и быстрее чем клиентов. Как минимум изменения доступны сразу после внесения их в серверный код и не нужно ждать пока обновленная версия клиента окажется в репозитории, пока пользователи обновятся и т.д.
Никакой сложности в варианте имеющемся сейчас нет - просто меня одного мало и код просто до конца не дописан так, как должен работать. Но уже сейчас более-менее понимающему, о чём речь, должен быть понятен механизм взаимодействия клиента с сервером. И на клиенте практически ничего менять не придётся, как минимум, сборка и отправка пробы это уже достаточно стабильный компонент, который, кстати говоря, даже можно оформить отдельным приложением/утилитой (все зависит от потребностей того, кто будет этим пользоваться, я же по большей части показываю демонстратор и часть ответа будет далее)
С учетом того что это непонятно кому нужно и никто явно не заявил заинтересованности в этом то можно смело на такую "сложность" забить на первом этапе.
В Росе тоже никому не нужна была система автосборки (условно назовем), но после того, как её разработчик донес это до многих маинтейнеров, те стали с успехом её применять. Так что ваш пример не в полной мере отражает ситуацию.
Считаю, что сложности в сопровождении серверного кода идут от того что сам сервер написан на bash-е. И имеет смысл переписать его на что-то стандартное.
Ошибочное представление. Сервис написан на php, на шелле там вспомогательные инструменты, которые непосредственно к самому сервису имеют весьма отдалённое отношение и при желании их можно реализовать на любом другом языке (потому как сервис достаточно модулен в этом плане).
Поскольку нам интересно, чтобы сервисом заинтересовалось ООО в планет его продвижения, то именно ООО и следует адресовать вопрос какая архитектура серверной части для них предпочтительна с точки зрения удобства развертывания и поддержки.
ИМХО слабый интерес к проекту со стороны ООО как раз и связан с нестандартной архитектурой сервера, которую непонятно кому и как поддерживать в случае если Автор потеряет интерес к проекту.
Так я не скрываюсь, исходники отослал, предложил свою помощь в плане ответов на вопросы. Но в ответ полная тишина, т.к. дело не в том, что не нравится архитектура, в а в том, что там не видят реальных кейсов для применения подобной разработки.

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 550
Я же постоянно акцентирую внимание на том, что сервис это по сути своей социальная сеть (с возможностью добровольного вхождения, т.е. регистрация это и есть отправка пробы и именно поэтому не должно быть никакого даже намёка на навязывание,
Еще одна социальная сеть? ИМХО бесперспективно, социальную сеть, чтобы она "наполнилась" пользователями должен продвигать кто-то более "тяжеловесный" чем ООО. К тому-же, отрицательно отношусь к всякого-года социальным сетям. При таком целеполагании проект мне становится не интересен.

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 550
Ошибочное представление. Сервис написан на php, на шелле там вспомогательные инструменты, которые непосредственно к самому сервису имеют косвенное отношение
Ну значит я ошибся. Мне показалось из переписки что там тоже был bash. Рад что я ошибся :-). Но php это тоже не мое.
Но в ответ полная тишина, т.к. дело не в том, что не нравится архитектура, в а в том, что там не видят реальных кейсов для применения подобной разработки.
Вот в эту сторону и нужно направлять усилия. На выявление интересных для ООО  кейсов и развития проекта в этом направлении.