Обсуждение и предложения по реализации базы данных проб оборудования

[sb]

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

Ответил в частности первым постом после вашего. Что ещё можно сделать для того (применительно к сервису), чтобы всё-таки начать изменение общественного мнения в исключительно практическом смысле (в самом широком смысле, в том числе и чиновников, работников образовательной сферы и т.д.) в пользу этого вашего линукса (https://vk.com/altlinux?w=wall-667081_25836%2Fall) ?

[asy]

Вот сколько сейчас в базе проб, которые были не только для статистики по железу сделаны, но и для того, чтобы логи посмотреть ? Кстати, а кто их может посмотреть ?

А вы спросите тех, кто пробы загружал. Я точно в их голову не залазил и мысли на расстоянии не читал. Но судя по запросам, логи вообще не востребованы

Похоже, что практически никто их от этой базы и не ждёт, что я и предполагал.

(очередной привет линуксоидам с "покажите лог x, y и z").

Логи нужны, когда разбирается проблема, а не когда надо посмотреть, работает ли та, или иная железка в Linux, и как. Немного подумал про dmesg. Вообще, этот вывод может представлять интерес, но исключительно примерно в таком виде:

Код: [Выделить]

dmesg|egrep "\[ +[0-9]{2}\."То есть, что там появляется спустя 100 секунд после загрузки вряд ли представляет интерес для HCL. Или, в край, заложиться на 200:

Код: [Выделить]

dmesg|egrep "\[ +1?[0-9]{2}\."Вот такое же точно никому не надо (а это просто сервер работает уже треть года):

Код: [Выделить]

# dmesg|head -n1
[10802475.539210] IN=eth3.2 OUT=eth6.321 MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=y.y.y.80 DST=x.x.x.2
01 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=256 PROTO=TCP SPT=64483 DPT=81 WINDOW=16384 RES=0x00 SYN URGP=0
Обычное ожидание от HCL, на мой взгляд, это посмотреть по базе по названию оборудования (pci/usb ID, упоминание моделей и т.п.), что оно у кого-то есть и работает, и всё. На сколько это нужно ? Вообще - нужно, но база должна быть достаточно большой.

[sb]

Похоже, что практически никто их от этой базы и не ждёт, что я и предполагал.

Я имел ввиду другую алгоритмику решения вопросов. Пользователь: "у меня что-то не работает, я даже сам не знаю, что и где, могу только про симптомы сказать". Желающие помочь:"показывайте логи, выводы команд, плюс еще вам дополнительные вопросы". Дополнительно пользователи вынуждены читать все те отступления от темы, что пишутся в рамках конкретной поставленной задачи. Не проще ли вместо всего этого сумбура просто собрать информацию и предоставить возможность получить к ней доступ. В теме, я уверен, станет намного меньше шаманства и плясок с бубном. Больше людей начнут понимать и разбираться, что вообще эти логи из себя представляют (в какой-то мере будет повышается грамотность использования систем даже простыми пользователеми). Темы будут минималистичными, только по сути и с минимумом воды. Сколько лет за форумом наблюдаю, а вода как была, так и есть. Только лица меняются да декорации, а по сути ничего вообще не меняется. Каким же образом линуксоидам добиться того, чтобы их система стала если не мейнстримом, то заметной и, самое главное, известной (на слуху) альтернативой не только для простого человека, но и для сотрудников госсектора, для которого важно импортозамещение.
Но логи не востребованы не потому, что объективно не востребованы, а потому, что я только вчера сделал черновой набросок доступа (надеюсь вполне удобного) к ним через веб-сайт.
А база оборудования как таковая, на мой взгляд, решает только весьма узкую задачу и баз этих уже достаточно для того, чтобы не писать очередную реализацию. Будет востребовано только комплексное решение, направленное на реализацию различных аспектов в использовании систем linux/gnu. Но, как я уже сказал, лично мне выгода от этого всего писания практически нулевая, а вот сообществу вполне может быть. Причём сообществу в широком смысле - обществу в целом для популяризации и продвижения. Хотя, конечно, поддержка уровня 0 (по низкоуровнему программированию в части драйверов и систем ядра) должна присутствовать, т.к. без неё не всегда может быть возможность просто решить вопрос работоспособности оборудования конкретного человека под управлением конкретной системы. Для чего, вообще говоря, и затевался сервис. Без участников с обеих сторон, очевидно, сервис обречен на забвение.

[sb]

Логи нужны, когда разбирается проблема, а не когда надо посмотреть, работает ли та, или иная железка в Linux, и как. Немного подумал про dmesg. Вообще, этот вывод может представлять интерес, но исключительно примерно в таком виде:То есть, что там появляется спустя 100 секунд после загрузки вряд ли представляет интерес для HCL. Или, в край, заложиться на 200:Вот такое же точно никому не надо (а это просто сервер работает уже треть года):

А вот это уже вопрос знаний конкретного человека (участника от одной из сторон - в данном случае назовём эту сторону условно "помощники"), как он будет логами пользоваться, что смотреть, в какой последовательности. Что он ещё найдёт (и захочет ли искать) такого, о чём изначально не было упомянуто в симптомах. Я ведь не делаю каких-то жёстких ограничений и прочих вещей, потому что все люди будут делать вами указанное по-своему. Зачем всех загонять в какие-то рамки. Проще и эффективнее дать им доступ к оригиналам (за некоторыми вычетами, о которых в том числе и вы говорили), а обработку их пусть каждый делает так, как удобнее и привычнее. Главное, чтобы достигался результат или хотя бы его наличие пусть и не в полном объёме.

[ASte]

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

[ASte]

Дополнительно пользователи вынуждены читать все те отступления от темы, что пишутся в рамках конкретной поставленной задачи. Не проще ли вместо всего этого сумбура просто собрать информацию и предоставить возможность получить к ней доступ. В теме, я уверен, станет намного меньше шаманства и плясок с бубном. Больше людей начнут понимать и разбираться, что вообще эти логи из себя представляют Темы будут минималистичными, только по сути и с минимумом воды.

Отступления от темы часто весьма полезны для расширения кругозора. Особенно для новичков.
Разбираться будут еще меньше - поскольку логи сами читать даже не будут пробовать.

[sb]

Разбираться будут еще меньше - поскольку логи сами читать даже не будут пробовать.

А вы думаете, что новички читают логи ? Что-то среди тех, кому я ставил, никто не только не смотрел, но и не знает, что это и где находится. Показать то покажут по указке, но зачем это делать, если есть виндовс, где вообще не надо знать всякие логи, команды, терминал и прочие вещи, там практически всё базовое работает (исключения крайняя редкость и скорее исключение из правил, поэтому вопрос стоит в том, что ресурсы сторон не сопоставимы в борьбе за того, кто будет применять инструмент либо виндовс либо что-то иное). Или у вас в запасе несколько жизней, чтобы до каждого донести и объяснить, необходимость каждому копаться в логах вместо того, чтобы, к примеру, писать стихи и романы, снимать кино, учить детей, стоять смену у станка. Вы вообще в реальном мире живёте ?

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

Линукс это долбаный инструмент по типу отвертки. И он должен просто выполнять свою задачу. Если он не выполняет или он очень непредсказуем, то совершенно справедливо люди выбирают другой, менее проблемный. Отступления полезны для общего развития - для развития возможностей человека по познанию мира и творчества. Не все будут досконально во всем линуксе разбираться, как и по сей день не все разбираются в виндовсе.

[asy]

Похоже, что практически никто их от этой базы и не ждёт, что я и предполагал.

Я имел ввиду другую алгоритмику решения вопросов. Пользователь: "у меня что-то не работает, я даже сам не знаю, что и где, могу только про симптомы сказать".

Но это - не Hardware Compatibility List ни разу, это именно хелпдеск.

Не проще ли вместо всего этого сумбура просто собрать информацию и предоставить возможность получить к ней доступ.

Я уже несколько раз повторил, что для решения проблем нужны логи в момент проблемы, а не в произвольный момент наполнения HCL. А для наполнения HCL лишняя информация ничего, кроме вероятных проблем, не несёт. Только и всего. Потому база HCL должна быть исключительно базой HCL, а хелпдеск - хелпдеском. Даже если где-то можно усмотреть их связь.

Но логи не востребованы не потому, что объективно не востребованы

Кому могут быть нужны логи в моих пробах, если я не прошу никакой помощи, а просто решил отправить список оборудования для HCL ?

А база оборудования как таковая, на мой взгляд, решает только весьма узкую задачу и баз этих уже достаточно

Она решает свою задачу и должна быть для каждой отдельно взятой ОС, потому для ALT Linux она тоже нужна (я исхожу из того, что каждый дистрибутив - отдельная ОС).

[Dmytro]

А база оборудования как таковая, на мой взгляд, решает только весьма узкую задачу и баз этих уже достаточно

Она решает свою задачу и должна быть для каждой отдельно взятой ОС, потому для ALT Linux она тоже нужна (я исхожу из того, что каждый дистрибутив - отдельная ОС).

Базы для Linux вообще есть. А конкретно для Altlinux других не видел. Именно поэтому нужна эта база.

Я уже несколько раз повторил, что для решения проблем нужны логи в момент проблемы, а не в произвольный момент наполнения HCL. А для наполнения HCL лишняя информация ничего, кроме вероятных проблем, не несёт. Только и всего. Потому база HCL должна быть исключительно базой HCL, а хелпдеск - хелпдеском. Даже если где-то можно усмотреть их связь.

Логичным выглядит разбить фунционал программы на 2 части: hardware и логи. И, допустим, 3 варианта запуска: железо, логи и фул.

[sb]

Я уже несколько раз повторил, что для решения проблем нужны логи в момент проблемы, а не в произвольный момент наполнения HCL. А для наполнения HCL лишняя информация ничего, кроме вероятных проблем, не несёт. Только и всего. Потому база HCL должна быть исключительно базой HCL, а хелпдеск - хелпдеском. Даже если где-то можно усмотреть их связь.

Простой пример: беру первую попавшуюся пробу. Комментариев нет, догадываюсь примерно, кто отсылал. Помощи не просил. Но я же логи просматриваю иногда. Так вот в логе я вижу проблемы, которые повторяются изо дня в день. Человек может быть закрывает на это глаза или у него как-то всё по-другому работает, но загрузка/незагрузка wifi прошивки может быть отслежена в любой момент до момента устранения. И это не единственный пример. А вы говорите только в конкретный момент. Тут я с вами категорически не согласен и имеющиеся логи (в том числе и по моей системе, которую я худо-бедно обслуживаю самостоятельно) это подтверждают. Также из логов на любой момент времени можно выловить массу интересного для специалистов уровня ядра-драйверов, которым бы всё это передать для устранения и учёта на будущее. Но нам нужны ведь только свежие и актуальные логи...

Кому могут быть нужны логи в моих пробах, если я не прошу никакой помощи, а просто решил отправить список оборудования для HCL ?

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

Она решает свою задачу и должна быть для каждой отдельно взятой ОС, потому для ALT Linux она тоже нужна (я исхожу из того, что каждый дистрибутив - отдельная ОС).

Вам больше подойдёт база росы: она принимает любые дистрибутивы, вроде бы можно указывать, что собирать, а что нет (хотя я не разбирался и не тестировал), есть статистика с графиками. Зачем тогда ещё один велосипед, к тому же узконаправленный (на данном этапе) ? Какая тогда разница, где копить, но ведь лучше копить там, где уже есть и много. А там достаточно большой массив.

[sb]

Логичным выглядит разбить фунционал программы на 2 части: hardware и логи. И, допустим, 3 варианта запуска: железо, логи и фул.

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

[asy]

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

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

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

1. Показывает. Я привёл пример содержимого dmesg в предыдущем сообщении. Там есть и MAC адреса, и IP адреса. Если бы я выложил пробу с этого сервера, к этому dmesg был бы доступ.
2. Я не знаю, что решит сделать в следующий момент владелец базы.
3. Я не знаю, взломают ли систему, где всё это хранится.

Если считаете, что надо сделать выбор для пользователя слать с логами или без логов, то я, наверное, соглашусь, но в этом случае никакого дополнительного функционала вроде комментариев

Вот комментарии, как раз, нужны. Дописать, если с каким-то железом из пробы есть известные проблемы.

[sb]

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

Но мы не ищем простых путей, к тому же это, на мой взгляд, единственный выход, чтобы

Вот комментарии, как раз, нужны. Дописать, если с каким-то железом из пробы есть известные проблемы.

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

1. Показывает. Я привёл пример содержимого dmesg в предыдущем сообщении. Там есть и MAC адреса, и IP адреса. Если бы я выложил пробу с этого сервера, к этому dmesg был бы доступ.

Хорошо, посмотрю потом повнимательнее (времено убрал dmesg из доступных логов). Но это единственная претензия как я понимаю к тому, что сейчас доступно, других возражений нет ?

2. Я не знаю, что решит сделать в следующий момент владелец базы.

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

3. Я не знаю, взломают ли систему, где всё это хранится.

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

[Dmytro]

Логичным выглядит разбить фунционал программы на 2 части: hardware и логи. И, допустим, 3 варианта запуска: железо, логи и фул.

Ну уж нет, увольте. Писать два клиента и два сервера...

Ну зачем 2? Можно и в пределах 1 реализовать. С серверной частью вообще проблем быть не должно. Все выводы факультативных данных обвязать if-ами, типа "если есть - показать, иначе сообщение".

С клиентской частью будет несколько сложнее. На вскидку вижу 2 варианта:
1. Пропустить результат того, что получается сейчас через парсер и вырезать лишнее.
2. Написать альтернативный сборщик, который меньше сведений запрашивает.

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

Вот комментарии, как раз, нужны. Дописать, если с каким-то железом из пробы есть известные проблемы.

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

[sb]

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

Не надоело на костылях то ходить ? :) Так вот иногда размышляешь, вроде и 21 век на дворе, а в линуксе костыль на костыле и костылём погоняет.

Что касается лично меня, я данные еще 2-3 проб, как до этих машин доберусь, закину.  Конкретно в моем случае даже открытая публикация этих данных ощутимого вреда не принесет.

Отключить то отключил приём, но переборщил. Проверку и комментарии как минимум надо вернуть...