Как я могу проверить, установил ли я небесплатное программное обеспечение?

Вот подход, с которым я пошел, он избегает использования PROMPT_COMMAND.

# This function is called from a subshell in $PS1,
# to provide a colourised visual indicator of the exit status of the last run command
__COLOURISE_EXIT_STATUS() {
    # uncomment the next line for exit code output after each command, useful for debugging and testing
    #printf -- "\nexit code: $1\n" >&2
    [[ 0 == "$1" || 130 == "$1" ]] && printf -- "$GREEN" || printf -- "$RED"
}

Затем мой $PS1 следующие:

PS1='# ${debian_chroot:+($debian_chroot)}'"${GREEN}\u${YELLOW}@${DARK_YELLOW}\h${WHITE}:${LIGHT_BLUE}\w${WHITE}\n"'\[$(__COLOURISE_EXIT_STATUS $?)\]# \$'"\[${WHITE}\] "
6
16.07.2013, 14:23
2 ответа

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

Я хотел бы эту функциональность на Fedora

Репозитории Fedora разделены на 'свободный' и 'несвободное'. По умолчанию только свободные репозитории используются. Таким образом, если Вы никогда не добавляли никакие другие репозитории, затем yum ничего не мог установить от них.

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

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

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

Само ядро не может содержать небесплатный код, оно может только закончиться в модуле. Если Вы загружаете источник с kernel.org и компилируете Ваше собственное, я не думаю, что он содержит что-либо того вида, начиная с отношения Linus ("Я отчасти принимаю их, но я никогда не поддерживаю их, и мне не нравятся они"), подразумевает, что несвободным модулям позволяют использоваться с ядром, но очень вряд ли быть распределенными надлежащим Linux (то есть, kernel.org). Собственные драйверы независимо распределяются; дистрибутивы затем включают их, не kernel.org (однако, согласно той странице "Forbidden Items", мягкая фетровая шляпа явно не включает собственные драйверы, по крайней мере, в 'свободном' repos по умолчанию).

Вы могли исследовать онлайн весь материал, перечисленный lsmod. Так как любой двоичный блоб должен быть модулем, мне кажется, это - то, где Вы найдете его.

Fedora рекомендует, если Вы хотите создать свое собственное ядро, использовать исходный пакет от них. Однако я использовал скрученные вручную ядра из ванильных источников kernel.org на мягкой фетровой шляпе в течение многих лет и никогда не имел проблему. Таким образом, если Вы - удобное выполнение это и не используете несвободные репозитории, у Вас не должно быть несвободного установленного материала.

3
27.01.2020, 20:28
  • 1
    Чтение этой строки: "Если это является собственным, это не может быть включено в Fedora. (Двоичное встроенное микропрограммное обеспечение является единственным исключением к этому)", сделал меня любопытным. Кроме того, иногда я включаю несвободные репозитории для некоторых программ/драйверов, и когда мне установили что-то больше года, я не знаю возможно, ли что-то, вытянули как зависимость от несвободного или установленного мной на несчастном случае. Я был бы, точно так же, как для проверки его это - все. Кроме того, я также знаком с тем "встроенным микропрограммным обеспечением = программное обеспечение на устройстве, не драйверы" определение, но мне определенно нужно больше информации об этом. –  jcora 16.07.2013, 16:42
  • 2
    @Yannbane было бы хорошо, если бы у них был явный, ведомый список "двоичного встроенного микропрограммного обеспечения", которое включено. Я воображаю, спрашиваете ли Вы правильного человека приятно, у них мог бы быть ответ - с этой целью я запустил поток здесь: forums.fedoraforum.org/showthread.php?p=1660611#post1660611 Прочитав ту страницу "Forbidden Items" далее, это явно, что Fedora не включает собственные модули ядра (если, я не предполагаю, если Вы получили их от несвободного repo). –  goldilocks 16.07.2013, 16:58
  • 3
    Однако, было бы замечательно иметь способ удостовериться. Стандартная установка не могла бы включать небесплатное программное обеспечение - но это могло бы закончиться там, и даже если бы это маловероятно, я все еще ценил бы просто проверку. –  jcora 16.07.2013, 17:00

Независимые ядра и модули

Сортировка пакетов:

Это проверено в системах Mageia / Redhat и т. Д.

1. Получите все использованные лицензии из всех ваших пакетов.

rpm -qia | grep "License" | sort

2. Узнайте, какая лицензия вам не подходит.

3. Выясните, какой пакет использует проблемную лицензию.

rpm -qia | grep ": Problematic License" -A 15 -B 20

Примечания:

vrms (для debian) и другие подобные инструменты хороши в теории, но когда дело касается реальности, они бесполезны, вы должны все проверить сами, если вы профессионал в области безопасности / конфиденциальности

Примечание 2:

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

  • Машина с открытым исходным кодом bios *

  • Получите хороший дистрибутив, например mageia или около того

  • Проверьте все пакеты и модули

  • Скомпилируйте собственное ядро ​​

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

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

Эти связанные инструменты ядра могут вас заинтересовать

http://tomoyo.osdn.jp/

http://akari.osdn.jp/

3
27.01.2020, 20:28

Теги

Похожие вопросы