mayton2019

Замер 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 формате. География - кстати очень интересная тема.
Особенно если данные географии накладывать на какие-то другие. Экология там... ковид. И прочее.

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

В идеале - реплицировать все данные в другую БД с другой геометрией таблиц или вообще в систему другого типа.

Любая современная биг-дата будет дешевле по стоимости владения по сравнению с DBMS.

Для хранения матрицы 10000 на 10000 в формате double вам понадобиться кусок памяти порядка 800 Мб.
И это только для хранения исходных данных. А если нужно будет искать всякие определители и обратные матрицы
то сложно себе представить сколько дополнительной памяти будет нужно.

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

Чем заполнить матрицы в данном примере - ХЗ. Надо погружаться в сам курсовой. Если он растет из физики то и исходные данные надо брать оттуда. Там всякие диагональные и треугольные и прочие.

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

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

Тоже сохраняет мототонность.

Да что за преподаватель такие задачи придумывает? Неужели не мог что-то полезное выдавить? Наверное нужно поменять ядрос ОС. Перекомпилировать по сути. Задача КМК нетривиальная для какой-то лабы. Тут - скорее можно получить кучу новой побочки даже не дойдя до решения лабы. Вобщем проще занести деньги на кафедру.

Если говорить языком фактов то в кодировке Base64 нельзя использовать символ "_", а можно только от буквы A до символа "/" в диапазоне ASCII. Где и как оказался символ подчеркивания - непонятно.

Обычно начинают с кодов Хемминга. Они - простые и исправляют 1 бит на блок.

Вообще, в стеке шифрования, коды восстановления не подмешиваются к шифроблокам, а скорее оборачивают как конверт.

Капс печатает логи ошибок здесь /var/log/cups
Посмотри какие там последние события.

Тут - какая-то обще-системная ошибка, и сообщение java.net.ConnectException: Connection refused: connect
совершенно не несет никакой информации где искать проблему. Давайте переведем задачу из плоскости Java в плоскость сетей и протоколов. Вобщем для начала надо подёргать порт снаружи используя утилиты telnet или netcat и далее уже смотреть по ошибкам.

nc -w 3 -zv tester17.com 33333

когда получишь сообщение : "Connection .... succeded!" - то можно возвращаться в Java кодинг.

Проблема кроется в самой постановке. Боту недостаточно убегать от красных. Ему надо заранее прокладывать траекторию так чтобы при равных скоростях они оба бегали бесконечно. Я так понимаю что это будет успех.

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

Из 40 человек - смотреть будут 1-2.

Остальные - полезет в youtube или Netflix.
Я не критикую саму идею. Просто может стоит подождать первой нагрузки а потом уже заняться оптимизацией по факту.

Вот ты чудак. Ты говоришь - я пишу рейкастинг. И код - кривой. Так либо ты не делай кривой. Либо скажи честно что скопировал в таком-то и таком-то интернет ресурсе.

Это наверное поможет вопроснику разобраться где там нужная функция.

Если посмотреть в историю - то JVM создавалась в 1996 году как платформа для встраиваемой техники. Холодильники. Кофеварки. Техзадание такое было. И разумеется в саму спеку были заложены ограничения которые позволят байткоду собираться даже на очень слабых машинах. Где мало регистров и мало разрядности. И мы имеем стековую машину (наподобие калькулятора МК-60) в которой принципиально нет регистровой адресации. В отличие от платформ .Net/clr где есть более современная адаптация к процессору. Вобщем если вы заходите написать код который будет friendly к SSE/AVX регистрам - то у вас ничего не выйдет. На уровне JVM - максимальная разрядность алгебраического типа - 64 бит (знаковые). Это как мне кажется наиболее сильное ограничение. И неизвестно когда спека будет расширена. Насколько я вижу Oracle и JCP очень консервативны в этом вопросе и неохотно вносят изменения в сам байткод.