Денис _______________, не RHEL, а RH. Когда-то существовал такой дистриб (бесплатный), наследником которого является Fedora. Но даже так, Mandrake не был основан непосредственно на пакетной базе RH, он сильно от неё отличался, и там даже пересборка srpm от RH и других rpm-дистрибов была с большим количеством бубна. ALT давно уже имеет свою пакетную базу Sisyphus, когда-то утверждали что она весьма неплохая и содержит дофига пакетов, но я не в курсе насколько хорошо её нынче ведут, да и у Fedora с тех пор тоже пакетная база сильно выросла.
Есть ещё и SUSE, который тоже на rpm-пакетах, но своих.
Если лезть в формальное родство и происхождение, то можно долго увязнуть в холиварах. Но простейший критерий тут всё же другой: грубо говоря, можно ли ставить один пакет в разные дистрибы. И вот в debian/ubuntu и их клоны часто можно спокойно ставить .deb-пакет, а вот с .rpm это часто работает очень хреново даже на близкородственныз дистрибутивах - не говоря уже о совсем различных.
Поэтому - нет, я не согласен, что rpm-based дистрибутивы это что-то одно и единое. Это только в мире deb-based работает (и то не всегда).
Ну и в целом никуда не девается претензия к тому, что все дистрибутивы намеренно сводятся к rpm-based и deb-based с отрицанием огромного зоопарка других пакетных менеджеров и вообще подходов (например, Elementary OS изначально основана на Ubuntu, но оперирует приложениями flatpak вместо deb-пакетов).
Sanes, есть довольно популярные дистрибутивы, которые нельзя отнести ни к Debian-based, ни к Fedora-based. Например, ALTLinux сочетает собственную пакетную базу rpm и пакетный менеджер apt. А уж о всяких Gentoo с ebuild'ами и Arch с pacman/aur я уж и не говорю. Ну тот же Alpine или OpenWrt со своими собственными пакетами и пакетными менеджерами довольно известны...
И это только очень известные дистрибутивы.
Поэтому люди не просто так констатируют узость мышления.
Drno, на самом деле это далеко не шутки. Можно почитать отзывы, там при любом чихе продавец сразу возврат предлагает, что намекает, что проблемы бывают часто. И скорее всего срок жизни железяки даже у довольных может быть небольшим, то есть отказов больше, чем мы видим. Ведь довольные люди чаще всего не меняют отзыв спустя даже считанные недели или месяцы. Придётся готовиться к отказам и возвратам, негативу клиентов итд.
Если всё равно потом менять, то даже партию на 100 штук покупать нет смысла, и я бы рекомендовал подумать над тем, чтобы сразу выбирать более адекватное конечное решение.
Tycoon86, если вокруг есть соседи с 2.4 ГГц, особенно гении с "завышу уровень сигнала в в потолок", то можно легко огрести. У меня в доме в какой-то момент регулярно стали секундные пинги на Wi-Fi, помогал только ребут роутера, и то порой не больше чем на полчаса, в итоге я перешёл на 5 ГГц. И всё стало хорошо.
2.4 ГГц может быть лучше в некоторых особых сценариях. Может бить дальше, особенно при наличии стен, но это если вокруг пустой или почти пустой радиоэфир. В городе же это совсем не вариант.
Можно попробовать направленными антеннами спарить, но результат не гарантирован. Был опыт много лет назад, когда два D-Link так обеспечивали радиомост на 200 метров между двумя школами, работало более-менее, но тогда и интернет школам выдавали в лучшем случае 2 Мбит/с, причём не всем - из-за чего и приходилось вот так исхитряться...
Drno, шить нужно всего один раз, а далее будет намного более удобно: прям из коробки куча настроек, софт оптимизирован по размеру, куча дополнительного устанавливаемого софта, всё готово для разделения на RO и RW с целью отделить прошиву от изменяемой части...
Причём шить некоторые модели можно вообще по tftp в момент их загрузки, поэтому будет достаточно включать их в сеть и зажимать кнопкочку...
А дешёвые китайцы вообще часто сразу идут с openwrt.
Наоборот, чем больше девайсов, тем больше смысла всем этим заниматься.
Полноценный Linux с systemd, dbus и кучей другого обвеса, с тяжёлым ядром и вагоном лишних модулей под GPU, звуковухи, периферию, море файловых систем и сетевых интерфейсов - зачем это нужно?
Зачем так много памяти и диска? Это будут не простые шлюзы в сеть, а с какой-то сложной ресурсоёмкой функциональностью?
Есть куча SOHO роутеров, которым столько не нужно, но со своей задачей они справляются. И на них нередко отлично шьётся openwrt или какой-нибудь ещё кастомный линукс. И у китайцев можно найти даже не сами роутеры, а всего лишь платы для них без корпуса.
Сильно сэкономить вряд ли выйдет, это нужно на очень большие партии рассчитывать. В дешёвом ценовом сегменте и так уже сэкономлено во всём, включая скидки за крупные партии.
Алексей, нет, общепринятая практика, что есть .h-файл с заголовками (описания типов, функций итд) и .c с кодом. В одну кучу это собирают при линковке. Примерно так:
dim5x, я склонен думать это google colab нарочно борется с такими пустыми циклами в своём интерпретаторе, добавляя фиктивные sleep или даже хотя бы перемещая по pass в конец очереди планировщика.
Делать процессородробительный цикл всё равно будет по-прежнему неправильно. И этому надо учиться сразу.
Можно установить что ssh-сервер, что ssh-клиент (сборку openssh от microsoft) на современную винду начиная с десятки. На проф-редакциях и выше - прям с помощью winget - но даже на хоум можно поставить из бинарного дистрибутива (в интернете полно объяснений).
А также rsync, mc итд. Я уж не говорю о возможности поставить на винду mingw/msys или wsl...
Также под Linux вполне работает samba. Тоже вполне вариант в некоторых сценариях. Webdav, ftp и другие-прочие варианты вряд ли имеют смысл, но они тоже имеются.
Adamos, справедливости ради стоит сказать, что Bitrix тоже когда-то распространялся зашифрованным (кажется, Zend Optimizer). Но потом они от этого всё же отказались.
dim5x, я не знаю что это за "пример кода" и что там за "железо" и как рисуются эти "графики". Но так делать всё равно НЕЛЬЗЯ. Потому что в другой раз эта ошибка дорого обойдётся. Потому что именно семантически бесконечный цикл без полезных действий в любом случае целиком исполняется процессором. В любом языке. Это надо сразу же знать и никогда не делать.
Кстати, и первичную задачу лучще было бы сделать thread.join() на любом из запущенных тредов. Если они всё равно бесконечны - он никогда не завершится.
dim5x, бесконечный цикл безо всяких действий полностью исполняется процессором и считается в user time, все миллионы и миллиарды итераций. А sleep приводит к системному вызову и стоит около нуля user time - штучное количество тактов процессора в секунду. Фактически это возврат управления операционной системе.
Это реально так и работает. Я не раз видел, как люди допускали подобную ошибку. Например, делали "ничего не делающий" цикл в bash, который по факту всё же "что-то делал" и выжирал одно процессорное ядро подчистую.
Конечно, может зависеть от операционной системы и конкретной реализации. В DOS, например, даже sleep всегда является циклом, потому что процессор полностью в распоряжении программы, операционная система включается лишь по запросу или в результате аппаратных прерываний. Но мы же говорим о полноценных современных многозадачных операционных системах.
Bearer Auth по определению имеет такой формат. Тут скорее всего нужно кастомный класс написать. С fastapi только какую-то простую мелочь писал, но вот для requests пару раз делал нестандартные авторизации - там нужно класс с нужным интерфейсом сделать и его передавать вместо умолчального.
lisi4ka, ещё замечание: при SELECT не надо делать COMMIT, ведь изменений нет. Ну кроме случаев, когда в SELECT вызывается функция, которая что-то изменяет в базе.
Тем более на каждой итерации даже при изменении данных COMMIT смысла не надо делать, обычно делают весь цикл изменений или всю серию или часть изменений и затем COMMIT скопом. Как пример, когда делается массовая вставка в таблицу, то можно каждые 10000 записей делать COMMIT, но не на каждую запись - это лишь замедлит операцию.
ter56, так как приложение само записывает звук, то вряд ли. Скорее можно записать звук другим приложением, обработать его и отправить как файл. Но это уже не будет голосовуха.
Есть ещё и SUSE, который тоже на rpm-пакетах, но своих.
Если лезть в формальное родство и происхождение, то можно долго увязнуть в холиварах. Но простейший критерий тут всё же другой: грубо говоря, можно ли ставить один пакет в разные дистрибы. И вот в debian/ubuntu и их клоны часто можно спокойно ставить .deb-пакет, а вот с .rpm это часто работает очень хреново даже на близкородственныз дистрибутивах - не говоря уже о совсем различных.
Поэтому - нет, я не согласен, что rpm-based дистрибутивы это что-то одно и единое. Это только в мире deb-based работает (и то не всегда).
Ну и в целом никуда не девается претензия к тому, что все дистрибутивы намеренно сводятся к rpm-based и deb-based с отрицанием огромного зоопарка других пакетных менеджеров и вообще подходов (например, Elementary OS изначально основана на Ubuntu, но оперирует приложениями flatpak вместо deb-пакетов).