Кстати, как на счёт недорогих переходников usb-lpt, которые только для печати?
Они поддерживаются, но не все принтеры с ними работают. Canon LBP-810, например, не заработал ни в Windows, ни в Linux, ему, видимо, нужно управление по доп. пинам.
Ваш HP 1100 это почти копия LBP-810, у него такой же Canon'вский printing engine, но плата форматтера (и прошивка, и драйверы) отличаются. Если у вас работает с Windows, то и через плату должно работать.
Почему не Docker-контейнер, который можно запустить на любом одноплатнике?
Прежде всего из-за сложности взаимодействия с udev hotplug из контейнера, и правильной реакции на эти события, определёнными сложностями с пробросом USB. Некоторые принтеры не имеют памяти под прошивку и ждут, пока компьютер загрузит её при каждом включении. Если и хост, и контейнер начнут что-то делать с принтером одновременно, он не будет печатать. Другие принтеры, например некоторые модели от Samsung, такие неженки, что никакому другому ПО на них лучше вообще не дышать, иначе зависнут.
Контейнер не сможет обеспечить той надёжности и повторимости, какой можно добиться от «голой» операционки, а подготавливать образы ОС для широкого спектра одноплатников точно не вершина моих мечтаний. Несколько проектов «контейнера для печати» уже существует, ни один из них мне не понравился.
Почему исходники не выложены публично?
Они не заработают в отрыве от конкретного железа (которое уже всё распродано и недоступно для покупки). Для DIY проще установить ПО и драйверы на одноплатник классическим методом, а не адаптировать целую ОС и систему сборки под ваше железо. Энтузиасты могут отправлять патчи непосредственно в задействованное ПО.
Всё же плата стоит менее трети от самого-самого дешевого нового принтера, но действительно, цена здесь играет решающую роль. Увы, дешевых одноплатников просто нет — прошли те времена, когда простые модели были по $9.99.
Если он работает, то принт-сервер ему не нужен.
Многим хочется банального удобства — возможности печати со смартфона не включая компьютера, либо возможности убрать принтер подальше от компьютера.
Сканер в mf4370dn поддерживается SANE'ом, работать будет, по крайней мере должен, драйвер в SANE вроде не сломан. Самая простая проверка — загрузить livecd ubuntu и попробовать посканировать. Если всё в порядке, то и на принт-сервере заработает. Если есть нюансы или работает нестабильно, то нужно будет отлаживать (мне).
Или почему не создали подобную архитектуру для смартфонов?
Потому что Android это операционная система для бытовых приборов, а не персональных компьютеров. В бытовом приборе у пользователя нет возможности ни переустановить ОС, ни изменить низкоуровневые компоненты, ни заменить одну деталь на другую.
Операционные системы для персональных компьютеров поставляются сторонними организациями, не относящимися к сборщику компьютера, поставщику материнской платы или процессора. Все производители компонентов должны написать драйверы под Windows, сертифицировать их у Microsoft электронной подписью, и удостовериться, что их устройство нормально работает, в идеале на любом компьютере. Вы, пользователь, покупаете копию операционной системы у компании.
Операционная система для бытового прибора идёт в составе прибора и поставляется производителем прибора. Производителю электронных компонентов не нужно связываться с создателями операционных систем, он пишет драйвер для Linux и передаёт его заинтересованному производителю прибора напрямую (а иногда поставляет только железо, и драйвер необходимо сделать производителю прибора).
Почему так? Почему модификации от Гугла не попадают в основную ветку?
Потому что ядро Android использует собственные подсистемы, отсутствующие в Linux, и не нужные в мейнлайне. Ранее также были особые оптимизации конкретно под телефоны, сейчас уже не уверен. Многое, что было полезно и можно было перенести в Linux, перенесли.
AOSP common kernels (also known as the Android common kernels or ACKs) are downstream of kernel.org kernels and include patches of interest to the Android community that haven't been merged into mainline or Long Term Supported (LTS) kernels. These patches can include:
Backports and cherry-picks of upstream functionality needed for Android features
Features ready for Android devices but still under development upstream
Vendor/OEM features that are useful for other ecosystem partners
Google (как и Microsoft) требует от производителя процессоров соблюдения определённых требований платформы, в частности, в плане безопасности.
Android поставляется с собственной эталонной реализацией всех этапов загрузки: littlekernel, fastboot, стандартов доверенной загрузки, разблокировки загрузчика, и т.п, и не требует поддержки ACPI. Производителю процессоров достаточно взять существующий код и добавить поддержку своего SoC.
UEFI-загрузка (и ACPI) приниципиально поддерживается, но реализации для неё нет. Производителю процессоров потребуется взять сторонний UEFI (открытый код TianoCore / лицензировать у Phoenix/AMI/кто там еще), написать сложный код ACPI (в котором ошибается даже Intel) вместо простого описания компонентов в DeviceTree, собственными силами напрограммировать и отладить все этапы загрузки, чтобы соответствовать требованиям платформы.
Если производитель наперёд знает, что чип будет использоваться только в смартфонах, ТВ-приставках и другом оборудовании на Android, нет никакого смысла идти против эталонных рекомендаций — это привнесёт ошибки, уязвимости, усложнит и удорожит разработку, с абсолютно нулевой разницей для конечного потребителя (а скорее всего, даже замедлит включение телефона из-за сложности UEFI).
Так как Windows on ARM требует UEFI+ACPI, последние процессоры от Qualcomm используют UEFI уже и на телефонах. Только ACPI-код заточен под Windows и никем не тестировался на Linux, он и не работает. Qualcomm работает над поддержкой Linux для самых свежих WoA-процессоров, но даже текущий roadmap содержит UEFI+DT, а не ACPI.
Только что нашел совсем свежую презентацию (сентябрь 2024) разработчика из Google, который описывает реализацию Android Generic Boot Loader поверх UEFI. Видимо, работы над этим ведутся.
Generic bootloader (GBL) is Android boot flow UEFI application provided by Google. Provide production ready open source Android boot flow reference implementation
Вендоры допиливают ядро под каждое новое устройство вручную, в результате или нет апдейтов или они дорого стоят, нет универсального дистрибутива
Поэтому же и нельзя купить произвольный смартфон и накатить на него произвольный Android/Linux/etc
Вы путаете причину со следствием.
В x86-мире процессоры делаются преимущественно для десктопов/лаптопов на Windows и серверов на Linux. Производитель процессоров пишет драйверы для этих ОС, добивается их интеграции в дистрибутивы (в Ubuntu есть отдельные OEM-ядра от каждого крупного производителя), удостоверяется, что вся периферия чипсета, совместимого с процессором, работает должным образом. И в случае с Windows, и в случае с Linux, производитель может разработать и поставлять драйверы независимо от Microsoft, ядра Linux и разработчиков дистрибутивов, но это менее удобно и ему, и конечным потребителям, особенно в Linux: добавив поддержку своего железа в ядро официально, все новые изменения, приходящие от сторонних людей, должны быть совместимы с уже существующим кодом, и ответственность обеспечить совместимость нового кода лежит на том, кто его добавляет.
В случае с ARM-процессоры для смартфонов разрабатываются… для смартфонов. Google поставляет модифицированное ядро Linux, определённой версии, со своими патчами под Android, и производитель добавляет поддержку своего железа в эту версию. Только Google, в отличие от людей, разрабатывающих ядро Linux, не осуществляет поддержку дополнительного кода. Переложить задачу на обеспечение совместимости вашего текущего кода с более новыми версиями Android-ядра не на кого. Вышла новая версия Android, требующая новой версии ядра? Будь добр, производитель процессоров, адаптируй свой референсный код и под ядро, и под Android. Для процессоров, спроектированных под смартфоны, задачи обеспечения совместимости с Windows и Linux не ставится — они создаются не под эти задачи.
В случае с ARM-процессорами для серверов задача ставится точно такая же, как и в случае x86-процессоров. Байкал, Huawei Taishan, Amazon Graviton — все загружают обычные ubuntu iso arm64 с официального сайта через UEFI с флешки, процесс с точки зрения пользователя от x86 не отличается.
Ну лет 10-15 назад была куча виндовых планшетов на Atom'ах N-серии. Но Интел просто перестала делать такие процессоры - и весь класс устройств просто вымер.
О чём вы вообще, рынок завален ноутбуками, convertable и мини-ПК на N95/N97/N100. Ренессанс.
Винда до сих пор занимает бОльшую часть рынка десктопов, при этом запускать на армах её просто негде, никаких арм-устройств нет в продаже за исключением Surface.
Еще Lenovo, Samsung. Меня несколько раз спрашивали про goodbyedpi под Windows ARM, а это софт с, может, 500 тысячами пользователей максимум. Это не гипотетическое пожелание, а люди на своих ARM-ноутбуках пытались запустить, и у них не заработало.
P.S. решил на выходных полноценно научиться работать с рейдом, начал экспериментировать, спустя 20 минут у меня уже локнулось ядро (ссылка 1). Ну, подумал, конфигурацию сделал нестандартную, опять edge case'ы не напрограммировали, с кем не бывает. Пошел читать mail list, а там у людей raid1 читает старые несинхронизированные данные с диска и разваливается посреди бела дня, а быстрое копирование файлов приводит к зависанию raid6, и всё это случается не на каких-то только из печи -rc, а результат работы одной из старейших и основополагающих подсистем ввода-вывода на стабильных версиях.
Мой основной интерес это роутеры, которые могут использовать в основном суммаризованные списки IP адресов
Блокировки осуществляются по доменам, и маршрутизировать их нужно по доменам. Однако маршрутизация так не работает. Все пытаются использовать существующие неподходящие инструменты, и не могут выбраться из этой парадигмы. Сбор IP-адресов — бесперспективное занятие, даже в сравнении с альтернативными, не менее костыльными методами.
На этом этапе (step 2 в исходниках) проверялось два основных критерия -
Доступность сайта по одному из способов - ping, http, https
Увы, не всегда сработает с доменами, заблокированными по *.зоне — на корневом домене может не быть записей, но домен при этом может активно использоваться. Либо же домен может не отвечать на ICMP и стандартные порты.
3-ий этап [...] был самым ресурсозатратным, по сути похож на первый, но на этом этапе нужно отфильтровать в том числе припаркованные домены и сайты с нормальными доменами, но бесполезным содержимым
Если совместить однократное/редкое сканирование по ключевым словам внутри страницы, а из результатов сделать список NS/IP, то процесс значительно ускорится.
В этом случае также разумно применить уплощение до зоны, это уменьшит количество доменов.
По итогам этого этапа осталось 41598 доменов
Ваш вариант со сканированием ключевых слов выглядит эффективным. Анализировали ли вы ложноположительные срабатывания? Список получился подозрительно маленьким.
Они поддерживаются, но не все принтеры с ними работают. Canon LBP-810, например, не заработал ни в Windows, ни в Linux, ему, видимо, нужно управление по доп. пинам.
Ваш HP 1100 это почти копия LBP-810, у него такой же Canon'вский printing engine, но плата форматтера (и прошивка, и драйверы) отличаются. Если у вас работает с Windows, то и через плату должно работать.
M1005 MFP работает полностью. Владелец принт-сервера починил все мелкие проблемы в открытом драйвере сканирования, и есть еще официальный от HP.
Отличное МФУ, которое до сих пор в цене. Родители как купили его в ~2008, так до сих пор активно пользуются, ныне через принт-сервер :D
Исходники действительно есть на сайте, только под паролем, который выдаётся при покупке.
И сразу ответы на никем не заданные вопросы:
Прежде всего из-за сложности взаимодействия с udev hotplug из контейнера, и правильной реакции на эти события, определёнными сложностями с пробросом USB. Некоторые принтеры не имеют памяти под прошивку и ждут, пока компьютер загрузит её при каждом включении. Если и хост, и контейнер начнут что-то делать с принтером одновременно, он не будет печатать. Другие принтеры, например некоторые модели от Samsung, такие неженки, что никакому другому ПО на них лучше вообще не дышать, иначе зависнут.
Контейнер не сможет обеспечить той надёжности и повторимости, какой можно добиться от «голой» операционки, а подготавливать образы ОС для широкого спектра одноплатников точно не вершина моих мечтаний. Несколько проектов «контейнера для печати» уже существует, ни один из них мне не понравился.
Они не заработают в отрыве от конкретного железа (которое уже всё распродано и недоступно для покупки). Для DIY проще установить ПО и драйверы на одноплатник классическим методом, а не адаптировать целую ОС и систему сборки под ваше железо. Энтузиасты могут отправлять патчи непосредственно в задействованное ПО.
Всё же плата стоит менее трети от самого-самого дешевого нового принтера, но действительно, цена здесь играет решающую роль. Увы, дешевых одноплатников просто нет — прошли те времена, когда простые модели были по $9.99.
Многим хочется банального удобства — возможности печати со смартфона не включая компьютера, либо возможности убрать принтер подальше от компьютера.
Сканер в mf4370dn поддерживается SANE'ом, работать будет, по крайней мере должен, драйвер в SANE вроде не сломан.
Самая простая проверка — загрузить livecd ubuntu и попробовать посканировать. Если всё в порядке, то и на принт-сервере заработает. Если есть нюансы или работает нестабильно, то нужно будет отлаживать (мне).
Билайн
МТС
Из договора с банком. В ВТБ24 это был отдельный, "неотключаемый" пункт, который по моей просьбе убрали из договора, перепечатав его.
Потому что Android это операционная система для бытовых приборов, а не персональных компьютеров. В бытовом приборе у пользователя нет возможности ни переустановить ОС, ни изменить низкоуровневые компоненты, ни заменить одну деталь на другую.
Операционные системы для персональных компьютеров поставляются сторонними организациями, не относящимися к сборщику компьютера, поставщику материнской платы или процессора. Все производители компонентов должны написать драйверы под Windows, сертифицировать их у Microsoft электронной подписью, и удостовериться, что их устройство нормально работает, в идеале на любом компьютере. Вы, пользователь, покупаете копию операционной системы у компании.
Операционная система для бытового прибора идёт в составе прибора и поставляется производителем прибора. Производителю электронных компонентов не нужно связываться с создателями операционных систем, он пишет драйвер для Linux и передаёт его заинтересованному производителю прибора напрямую (а иногда поставляет только железо, и драйвер необходимо сделать производителю прибора).
Потому что ядро Android использует собственные подсистемы, отсутствующие в Linux, и не нужные в мейнлайне. Ранее также были особые оптимизации конкретно под телефоны, сейчас уже не уверен. Многое, что было полезно и можно было перенести в Linux, перенесли.
https://source.android.com/docs/core/architecture/kernel/android-common
Google (как и Microsoft) требует от производителя процессоров соблюдения определённых требований платформы, в частности, в плане безопасности.
Android поставляется с собственной эталонной реализацией всех этапов загрузки: littlekernel, fastboot, стандартов доверенной загрузки, разблокировки загрузчика, и т.п, и не требует поддержки ACPI. Производителю процессоров достаточно взять существующий код и добавить поддержку своего SoC.
UEFI-загрузка (и ACPI) приниципиально поддерживается, но реализации для неё нет. Производителю процессоров потребуется взять сторонний UEFI (открытый код TianoCore / лицензировать у Phoenix/AMI/кто там еще), написать сложный код ACPI (в котором ошибается даже Intel) вместо простого описания компонентов в DeviceTree, собственными силами напрограммировать и отладить все этапы загрузки, чтобы соответствовать требованиям платформы.
Если производитель наперёд знает, что чип будет использоваться только в смартфонах, ТВ-приставках и другом оборудовании на Android, нет никакого смысла идти против эталонных рекомендаций — это привнесёт ошибки, уязвимости, усложнит и удорожит разработку, с абсолютно нулевой разницей для конечного потребителя (а скорее всего, даже замедлит включение телефона из-за сложности UEFI).
Так как Windows on ARM требует UEFI+ACPI, последние процессоры от Qualcomm используют UEFI уже и на телефонах. Только ACPI-код заточен под Windows и никем не тестировался на Linux, он и не работает. Qualcomm работает над поддержкой Linux для самых свежих WoA-процессоров, но даже текущий roadmap содержит UEFI+DT, а не ACPI.
Только что нашел совсем свежую презентацию (сентябрь 2024) разработчика из Google, который описывает реализацию Android Generic Boot Loader поверх UEFI. Видимо, работы над этим ведутся.
https://en.wikipedia.org/wiki/Server_Base_System_Architecture
Вы путаете причину со следствием.
В x86-мире процессоры делаются преимущественно для десктопов/лаптопов на Windows и серверов на Linux. Производитель процессоров пишет драйверы для этих ОС, добивается их интеграции в дистрибутивы (в Ubuntu есть отдельные OEM-ядра от каждого крупного производителя), удостоверяется, что вся периферия чипсета, совместимого с процессором, работает должным образом. И в случае с Windows, и в случае с Linux, производитель может разработать и поставлять драйверы независимо от Microsoft, ядра Linux и разработчиков дистрибутивов, но это менее удобно и ему, и конечным потребителям, особенно в Linux: добавив поддержку своего железа в ядро официально, все новые изменения, приходящие от сторонних людей, должны быть совместимы с уже существующим кодом, и ответственность обеспечить совместимость нового кода лежит на том, кто его добавляет.
В случае с ARM-процессоры для смартфонов разрабатываются… для смартфонов. Google поставляет модифицированное ядро Linux, определённой версии, со своими патчами под Android, и производитель добавляет поддержку своего железа в эту версию.
Только Google, в отличие от людей, разрабатывающих ядро Linux, не осуществляет поддержку дополнительного кода. Переложить задачу на обеспечение совместимости вашего текущего кода с более новыми версиями Android-ядра не на кого. Вышла новая версия Android, требующая новой версии ядра? Будь добр, производитель процессоров, адаптируй свой референсный код и под ядро, и под Android.
Для процессоров, спроектированных под смартфоны, задачи обеспечения совместимости с Windows и Linux не ставится — они создаются не под эти задачи.
В случае с ARM-процессорами для серверов задача ставится точно такая же, как и в случае x86-процессоров. Байкал, Huawei Taishan, Amazon Graviton — все загружают обычные ubuntu iso arm64 с официального сайта через UEFI с флешки, процесс с точки зрения пользователя от x86 не отличается.
О чём вы вообще, рынок завален ноутбуками, convertable и мини-ПК на N95/N97/N100. Ренессанс.
Еще Lenovo, Samsung. Меня несколько раз спрашивали про goodbyedpi под Windows ARM, а это софт с, может, 500 тысячами пользователей максимум. Это не гипотетическое пожелание, а люди на своих ARM-ноутбуках пытались запустить, и у них не заработало.
А сколько в России теперь пользователей IPv6-то, уух!
Мейнтейнер подсистемы RAID в Linux — Huawei.
Ну, технически, ревьюер, но вы понимаете.
https://lore.kernel.org/linux-raid/CAPhsuW72021iJDQp1HnJycpkp2GQOFvL9MGWGQ1LvMbr9-bWoQ@mail.gmail.com/
https://github.com/gregkh/linux/blob/42f7652d3eb527d03665b09edac47f85fb600924/MAINTAINERS#L21306
Hidden text
P.S. решил на выходных полноценно научиться работать с рейдом, начал экспериментировать, спустя 20 минут у меня уже локнулось ядро (ссылка 1). Ну, подумал, конфигурацию сделал нестандартную, опять edge case'ы не напрограммировали, с кем не бывает. Пошел читать mail list, а там у людей raid1 читает старые несинхронизированные данные с диска и разваливается посреди бела дня, а быстрое копирование файлов приводит к зависанию raid6, и всё это случается не на каких-то только из печи -rc, а результат работы одной из старейших и основополагающих подсистем ввода-вывода на стабильных версиях.
Блокировки осуществляются по доменам, и маршрутизировать их нужно по доменам. Однако маршрутизация так не работает. Все пытаются использовать существующие неподходящие инструменты, и не могут выбраться из этой парадигмы. Сбор IP-адресов — бесперспективное занятие, даже в сравнении с альтернативными, не менее костыльными методами.
Возможные решения описал здесь: https://ntc.party/t/варианты-маршрутизации-отдельных-доменовпрограмм-в-vpn/11408
См. https://bitbucket.org/anticensority/antizapret-pac-generator-light/src/master/config/exclude-regexp-dist.awk, здесь ключевые слова, которые отсеят зеркала, присутствующие в вашем списке.
Увы, не всегда сработает с доменами, заблокированными по
*.зоне— на корневом домене может не быть записей, но домен при этом может активно использоваться. Либо же домен может не отвечать на ICMP и стандартные порты.Один из вариантов оптимизации фильтра припаркованных доменов — по именам из NS-записей или по IP-адресам ответов. См. https://bitbucket.org/anticensority/antizapret-pac-generator-light/src/1cef07bd0d6c17e9668e244925c32af100aa97be/scripts/resolve-dns-nxdomain.py#lines-28
Это быстрее, но необходимо вручную собрать адреса парковочных страниц/NS.
Если совместить однократное/редкое сканирование по ключевым словам внутри страницы, а из результатов сделать список NS/IP, то процесс значительно ускорится.
В этом случае также разумно применить уплощение до зоны, это уменьшит количество доменов.
Ваш вариант со сканированием ключевых слов выглядит эффективным. Анализировали ли вы ложноположительные срабатывания? Список получился подозрительно маленьким.
https://flibusta.is/comment/3561973#comment-3561973
В zlibrary книги хранятся в IPFS (это такой bittorrent для web). Сам же сайт не распределён.
https://github.com/ValdikSS/GoodbyeDPI/issues/378
Да откуда вы это берёте, и нахрена? То
-e 9.5посоветуют, то-11.