mayton2019

Не спец в питонах. Но если getAll возвращает списки то их можно соединить через +.

list1 = xpath('//li[@class="section-list-item"]/a/@href').getall()
list2 = xpath('//a[@class="article-list-link"])/a/@href'). getall()
result = list1 + list2

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

Можно посмотреть в каталог MuzicBrainz https://ru.wikipedia.org/wiki/MusicBrainz

Ключевая фраза

Если отфильтровать данные по пользователю а затем по работе, то пагинация сломается (записей будет меньше, чем мы ожидали бы увидеть)

Мне кажется что здесь надо просто с бизнесом обсудить что собственно надо публиковать. С фильтрацией или без. А пагинация - это просто технический приём. К корректности результата вобщем то не имеет прямого отношения.

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

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

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

Можно посмотреть стандартный туториал по Spring+Mongo https://spring.io/projects/spring-data-mongodb

Хеш-таблица - это не массив. Хотя она может опираться на массив как на базовую структуру хранения (в случае метода открытой адресации). В классическом варианте хеш таблица - это совокупность структур данных в памяти. Массив массивов. Или массив списков (как будет угодно).

Про количество элементов - это сложный вопрос. Хеш таблица (ХТ) обычно резервирует памяти чуть больше чем надо. И экстендится когда памяти не хватает. Там для экстенда есть отдельный алгоритм. Можно считать что оверхед такой хеш-таблицы больше чем у массива. А количество элементов фактически - хранится отдельным счетчиков.

Вообще русская wiki достаточно хорошо описывает ХТ и можно начать читать с нее и далее по ссылкам.

Можно брать любой симметричный алгоритм и разделив его ключ на 2 половинки передать его лицам принимающим решение. Получается что-то вроде схемы Шамира. Нужен кворум людей чтобы сделать какое-то важное дествие.

Если я верно понял вопрос.

Возможно топик уже неактуален. Но я спрошу.

В наше время все хотят затащить в проект НС потому что это стильно и модно и кроме того наличие тега НС очень сильно может впечатлить заказчика. Но может быть настало время переосмысления НС и рассмотрения старых добрых проверенных методов?

Почему-бы не попробовать авто-корреляционную функцию. И если она будет лучше и проще - разве это не будет решением задачи?

Непонятно зачем в теме вопроса добавлено уточнение про GIL. Это специфика Python?

Добавлю что понятие процесса и потока может уж очень сильно отличаться в разных средах. Процесс в Erlang/OTP - это по сути актор который существует в сильной изоляции от всего остального мира и шарит память с другими процессами только через систему месседжей. Поток в Java - вообще не мапится в поток операционной системы.

Тоесть когда говорим о процессах и потоках то желательно сужать это определение до конкретной ОС и системы разработки.

Бесполезно учить АСМ в вакууме. Он - тоже часть экосистемы программирования железа и сетей. Если у вас например есть performance issue и требуется глубокий анализ того как С++ сгенерировал код и почему - тогда вам дорога в АСМ. Если такой задачи не стоит - то знания асма будут не нужны вообще.

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

Чтобы просто почитать память процесса - ему можно послать сигнал SIGQUIT и он должен ссыпать самого себя в дамп файла. Это законный метод. Программист пытается понять state процесса.

Все прочие методы должны вызывать настоящий ужас спецов по инфо-безопасности. Кому понадобилось изменять чужие процессы? Какой юзкейс?

Если компиллятор глотает оба варианта и тесты проходят - то я-бы взял просто первый вариант.

Там меньше букв.

Для новичка лучше не использовать LVM. Помимо того что это легаси софт она еще и не самостоятельый. Все равно нужно затаскивать конкретные файловые системы. Это создает определенную путацицу и вообще - правильно использовать утилиты lvcreate/vgcreate/pvcreate и не напортачить при этом - большое искусство. Готов спорить что с 1 раза ничего не выйдет.

+1 к btrfs.

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

Замер i/o это хитрая штука. Тут недостаточно просто программирования. Нужно знать что ОС обычно берет на себя часть функций по управлению (планировщики) вводом-выводом и кеширование.

Тоесть если ты будешь тестить свои программы в порядке 1->2 то вторая будет иметь фору в виде прогретого дискового кеша. И нужно делать хотябы -4-6 экспериментов чередуя 1->2->1->2 несколько раз и собирать кумулятивное время для каждого приложения и потом брать арифметическое среднее.

Данный класс Timer в таком виде не нужен. Он слишком прост и его можно заменить в коносли на вызов

$ time yourapplication

В качестве улучшений таймера я-бы сделал StopWatch. Это таймер который можно вызывать несколько раз и он будет кумулятивно считать время между begin-end и выводить его в конце. Так можно мерять интересующие фрагменты кода которые работают только с диском и игнорировать например вычисления с CPU.

Каналы в телеге можно глянуть

https://t.me/hadoopusers
https://t.me/apache_spark
https://t.me/devsp

Есть еще куча групп в ЛинекдИн и Фейсбуке. Но насколько я понимаю в РФ они зобанены.

Очень удивило наличие у вас вопроса по IRC-каналам. Удивлен что вообще кто-то это использует.

Для перехода с Log2j на вторую версию есть мигрейшен гайд https://logging.apache.org/log4j/2.x/manual/migrat...

Еще покажите полностью dependency:tree начиная с корня. Старый логгер log4j еще может быть транзитивной зависимостью от тысяч других библиотек (hadoop например) и выкорчевать его из проекта совсем - может быть нетривиальной задачей.

По поводу угроз которые были обнаружены в Log4j я-бы не сильно парился. Для современного биг-дата приложения которое запускается в контейнерах я думаю что угрозы нет. Если инициатива выкорчевывания библиотек исходит не от вас а от других людей - то неплохо-бы от них получить какое-то обоснование зачем все это делать и как много человеко-часов вы согласитесь вообще на это потратить.

Если искать документацию по протколам SMB/CIFS то все дороги ведут в Microsoft.
А у Microsoft вроде-бы нет концепции файловых битовых масок rwx. У них - больше ACL.

У гугла есть открытые учебные датасеты. Можно их посмотреть. Там и графика. И финансовая информация.

По поводу терабайтов в открытом доступе. Я не находил. В рамках студенческой дипломной работы трудно будет найти бесплатное облако или кластер который будет способен перемалывать терабайты за доступное время. Поэтому я-бы не ставил упор на объём.

Но можно найти гигабайты. Географические базы. https://www.openstreetmap.org/
Там есть данные по 40 гигабайт в XML формате. География - кстати очень интересная тема.
Особенно если данные географии накладывать на какие-то другие. Экология там... ковид. И прочее.