В UNIX тоже обычно расшаривают через samba, так как nfs немного для другого предназначен, работает поверх rpcbind в локальной сети безо всякой авторизации (ну, kerberos можно навертеть, но это задача с десятком звёздочек) и работать будет только на UNIX-системах. На телефонах, например не годится.
Я у себя шарю через самбу и одновременно через nextcloud (как external storage: local). В итоге можно или через тот же vlc на телефонах смотреть/слушать видео/аудио, или прям в мобильном клиенте nextcloud даже не только в локалке, но с авторизацией.
system_sudo, подход django состоит в том, что только в отладочном режиме django обслуживает файлы (это накладно и блокирует django при запуске в runserver, который по определению однопоточный). Статику полагается перекладывать в отдельнй каталог из всех django-приложений (коих может быть много в большом проекте) с помощью manage.py collectstatic, а этот каталог нужно явно раздавать через веб-сервер мимо django. Для медиафайлов всё почти так же, только медиафайлы сразу же кладутся туда, где их будет забирать веб-сервер всё так же мимо django.
Код python без отступов - не код. В нём вообще ничё понять нельзя. Для оформления кода на панели есть предпоследняя кнопка, используй её, иначе никто даже вникать в вопрос не будет.
nedland, эта ссылка скорее всего на m3u-лист, и его не так надо качать, а достав из него список ссылок и склеив эти файлы в mpeg-ts, который потом лучше правильно обработать. И то, m3u поддерживает криптографию, при которой видеофайлы шифруются и всё это становится не так просто.
Всё это умеет youtube-dl, но его надо правильно готовить. Придётся сидеть и вникать. Я в своё время ломал anidub и некоторые другие сайты и таки справился.
1. Индекс, в котором хранится offset начала каждого диапазона записей для префикса ключа (диапазона ключей).
2. Индекс можно сделать в виде дерева, где иерархически ключ разделен на части. Например, ключ длины 4, 8, 12 адресует смещение и длину блока с записями с префиксом ключа такой длины.
3. Можно использовать хеширование ключа, но скорее всего не получится быстрее для отсортированных данных, ведь индексироваться будет каждая запись отдельно.
А дальше научиться как базы выбирать, когда эффективнее full scan файла, а когда - хождение по ключу.
Пример (на базах данных, для понимания):
Пусть у нас есть таблица с записями о платёжных операциях, в котором есть поле bank (текст, bank_id - неважно, просто есть). Тогда если выбирать из таблицы маленький банк (какой-нить Мухосранский Народный Банк), то поиск по индексу эффективнее: мы сходим в индекс (который меньше самой таблицы), получим немного смещений в основной таблице и вычитаем немного блоков с диска с данными. Если же выбрать Сбербанк, который упоминается в более чем 80% записей, то хождение по индексу будет означать, что мы всё равно вычитаем всю или почти всю таблицу, и обращения к индексу увеличат наши расходы больше, чем мы сэкономим. Поэтому у зрелых баз данных есть разные сложные оценки запросов, включая всяческую эвристику и накопленную по предыдущим запросам статистику.
Ну так вот, плясать с файлом в 10 Гб надо от того, какие именно действия с ним производятся. Если, например, нужно всё равно перебирать все записи - то всё равно придётся перебирать все, и ничего мудрить тут вообще не надо. Дисковый кэш в ОС всё сделает за нас, если читать мы будем последовательно хоть по байту, хоть по мегабайту.
Если же профиль конкретный действий сильно разный (иногда читаем всё, иногда одну запись), то может оказаться эффективным реализовать два разных алгоритма, один из которых будет использовать индексирование, а другой нет.
В целом записи по 20 байт слишком маленькие, чтобы индексировать каждую запись. Но так как данные отсортированы, то индексировать диапазон может быть приемлемо - особенно если грамотно выбрать длину диапазона.
Наконец, я бы попробовал рассмотреть вариант просто загрузить этот файл в полноценную базу данных и отдал бы всю мороку по оптимизации доступа ей. Возможно, это будет быстрее наколеночных решений.
Нужно понимать, что любые такие способы это больше полумеры. Надёжный только один: не принимать платежи извне РФ, находясь в РФ, и даже с Казахстаном есть риски. Например, открыть юрлицо или ИП в совсем другой стране. Но при таких малых оборотах это слишком накладно, так что придётся искать рискованные способы с высокими комиссиями.
Roman32V, во многих CRM и не только CRM есть готовые интеграции или отдельно доставляемые модули с разными поставщиками. У кого-то REST, у кого-то SOAP, у кого-то SMPP, и суть каждого модуля в том, что его включаешь, забиваешь полученные у поставщика реквизиты и вот тебе готова интеграция.
То же самое с интеграциями с менеджерами, в том числе через коммерческих провайдеров (Viber, WhatsApp), тот же живосайт или битрикс24 поддерживают разных.
Добавлю, если образы остаются храниться у тебя, то надо оговорить с заказчиком условия. Например, что за аренду места под образы и обеспечение их сохранности столько-то денег. И, конечно, рецепт сборки сохранить в любом случае.
Так-то можно заказчику поднять gitlab, harbor или ешё кучу других решений для хранения образов, либо помочь арендовать какой-нить registry SaaS.
pfg21, тоже вариант. Просто это работает, когда точно знаешь занятые IP и лучше с мак-адресом сразу. А когда хочется забронировать "вот эти не брать", то лучше как раз указать какие брать можно.
MeredithMcGlynn, у меня был случай, сеть условно 192.168.0.0/24, шлюз .1 на оборудовании провайдера, DHCP-сервер 192.168.0.2 на собственном оборудовании организации. Мигнуло питание, оборудование провайдера ожило позже собственного, и IP .1 был DHCP-сервером выдан какому-то из компов. Причём интернет даже слега работал для тех устройств, которые получали правильный ARP шлюза :) Я тогда разбирался как в том устройстве ограничить диапазон выдаваемых IP, чтобы такое не повторилось.
Так что сценарий выдачи уже занятых IP вполне возможен. Например, если на момент выдачи с точки зрения DHCP-сервера занятый IP не был виден. Или если DHCP-сервер криво написан и не проверяет это нормально...
Смотря почему именно не включается. Вытаскивал файлы с Samsung с умершим экраном, загрузил, подключил, вслепую подтвердил подключение по USB к файлам (примерно представляя, где соответствующая кнопка должна быть, затем вытащил.
Вообще, можно начать с попытки попасть в recovery mode. Особенно если прошит кастомный с нормальными расширенными функциями. Если даже в recovery нельзя попасть, то скорее всего без прямого подключения к к SD-карточке на плате ничего не получится.
Что это за нелепое заблуждение, что траблшутинг это отладка на проде? Это же чушь полная.
Даже идеально написанное и тщательно оттестированное решение может от чего-то начать работать не так как надо. Причём даже не всегда по вине самого решения. Например, закончились ресурсы, поехал план запроса в базе, mtu слишком велик для пролезания пакетов в vpn, с внешней стороны прилетело что-то, что неправильно распарсилось либо наоборот, что-то внешнее отвалилось/тормозит/неадекватно отвечает итд итп. И всё это надо обнаружить, изучить, починить и порой даже принять меры к недопущению в дальнейшем.
А в реальности у идеального приложения могут возникнуть проблемы даже через годы успешной эксплуатации. У нас был случай, когда из-за какой-то неаккуратной (non-threadsafe) работы с данными после двух одновременных запросов в объект записалась дата с годом 23004, которая не смогла вставиться в базу и из-за особенностей приложения начала вставляться с бесконечным числом попыток. Разработчики это позже исправили, но мне-то пришлось решать как починить сдохшее приложение прямо здесь и сейчас, а не когда разработчики доберутся. И что интересно, проявилось на экземпляре, в котором от силы полсотни запросов в сутки, хотя баг был во многих компонентах, в том числе с миллионами запросов.
Сначала 3 месяца стажируют одного, потом другого, потом третьего... А в итоге у конторы есть бесплатный программист. Причину вообще не нанимать человека через 3 месяца найти всегда можно.
ssmende, если заходить с мобилы в аккаунт или даже из браузера, то Geolocation API даёт инфу о местоположении. Вот с этим для начала надо бороться. А там те же Wi-Fi сети, мобильные вышки итд... И разного рода эвристика. Это же всё делается не столько для точного определения положения, сколько для того, чтобы, например, при заходе на сайт магазина предложить фильтр по городу. И даже если будет ошибка иногда - ну и ладно.
Меня как-то Яндекс начал пихать в Оренбург, показывать магазины и вебкамеры на какой-то улице из этого города. Хотя я никогда там не был вообще. Видимо, ему в какой-то момент что-то ошибочно приглючило... И начало прилипать к моему профилю что-то оренбургское. Точно так же к профилю пользователя хорошо может липнуть любая другая случайно зацепленная локация.
Я у себя шарю через самбу и одновременно через nextcloud (как external storage: local). В итоге можно или через тот же vlc на телефонах смотреть/слушать видео/аудио, или прям в мобильном клиенте nextcloud даже не только в локалке, но с авторизацией.