mayton2019

Обычно настраивают JAVA_HOME - это корень дистрибутива.
CLASSPATH - это там где лежит lib/*.jar и
PATH - это где bin/ и все выполнимые приложения из
комплекса JDK.

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

Седжвик делает упор на алгоритмы. Вот и читай про алгоритмы. Сортировки. Поиск. Алгоритмы на графах.

Или ты думаешь что документация по Java раскрывает тебе графовые алгоритмы?
Бери содержание и смотри.

Файлы должны синхронизироваться в двунаправленном порядке (не зеркало).

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

Да. Поступать можно. Современный программист для сайтов e-commerce не претендует на особые
знания. Умеешь складывать и считать процент - этого достаточно.

Если будешь искать потом углубления - то подучишь потом. А так последние 10 лет это почти гумантиврная
специальность и софт-скиллы требуются в основном гуманитарные. Умение разговаривать. Знание английского.
Скрам-аджайл - это все гуманитарщина.

Это так не работает. Тут есть квантовый эффект что если ты подглядываешь за кодом
то он ведет себя так. А если уберешь эту формулу расчета длины то код будет собран
совсем другой.

int f(int a, int b) {
    return a + b;
}
void _end(void) {};

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

И трюки которые работали в ассемблере могут не работать для языков где есть агрессивная
оптимизация.

Вот допустим изучу я ассемблер и C, как будто это самое легкое из всего.

Это - вершина айсберга.

Если ты начнешь изучать например ассемблер для x86, то это целая история изменений. 16/32/64 регистры
и наборы команд для векторизации. Я-бы сказал что это все очень затягивает и это автоматически
вовлекает новые области знаний такие как - железо, микро-контроллеры, сети.

Далее может быть направления - системотехника и безопасность. Далее - оптимизация (параллелизм
и конкуренция).

Тоесть на самом деле нельзя сказать что я вот "изучу С" и положу книгу на полку. Это - как и зучить
современную физику. У тебя всегда будут открытые вопросы. И их число будет только расти.

Вобщем удачи.

Хм. Да похоже AWS.S3 действительно не поддерживает откат бакета в прошлое.
Но если рассматривать S3 как протокол поверх обычной файловой истемы
(Minio+BTRFS/ZFS) то вы можете задачу отката переформулировать в терминах
конкретной файловой системы. Там - это коробоная фича.

Я тоже думал над этим вопросом.

Я думаю что можно оценить влияние ИИ на текст как близость текста к учебному датасету.
И чем ближе ответ ИИ к учебке - тем с большей вероятностью он создан ИИ.

И чем дальше - тем он более нестандартный и очеловеченный

Как видите, для ответа на вопрос вам придется потрудиться. Как минимум собрать всю библиотеку Гуттенберга,
всю Британскую Энциклопедию, Фейсбук, Stackover e.t.c. :)

Инкапсуляция не имеет никакого отношения к хакерам.

Это просто свойство объекта иметь оболочку, которая защищает объект от неправильных изменений.
Неправильные изменения это например корректировка одного поля, которое на самом деле
функционально связанно со всеми другими полями. Например строка и контрольная сумма к строке.
Или время и часовой пояс времени. Или иммутабельность объекта.

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

И по протоколу, когда скачивание полностью завершено, все торрент-клиенты еще раз проверяют
целостность скачанного и если хотя-бы 1 бит не совпадает по контрольной сумме то закачка будет
продолжаться бесконечно пока сумма не совпадет.

Поэтому совершенно непонятно чего автор решил что он теряет пакеты?

Хорошая архитектура БД должна быть толерантной миграции версий. Например
если состояние пользователя хранится в XML то можно договориться что поле
"coins" (количество монет имеет дефолтное значение = 0) и не требует
принудительного обновления всех записей. Фактически это поле сохранится
в save файл только когда игрок заработает не нулевое число coins.

<player name="Иванов" coins=12 />
<player name="mayton" />

При моем подходе никакая миграция БД не нужна.

Мне эта модель также напоминает "schema evolution" из области BigData.

В ситуации когда в компании - бардак, все понятно.

Но имеет смысл проанализировать действия пользователя и понять зачем они хранят те или иные документы.
Например если это бухгалтерия, то почему они до сих пор не в системе а в рассыпухе Excel.

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

Короче проведите анализ использования десктопов и после этого - плановое обучение всех как использовать
корпоративные ресурсы вместо своего ХДД.

Это вообще задача не техническая а организационная. Сделайте участкового
админа и дайте ему все прививлегии. Зачем играть в эту игру с придумыванием
запутанных схем? Опыт инфо-безопасности показывает что все эти схемы просто
не работают. Про это Керхкофс писал.

Если политика сложности пароля недостаточная - придумайте политику. Обучите
людей чтоб не было совсем уже явных проколов на участках.

Будет использован invokevirtual

class MyClass
{
   public void method()
   {
     System.out.println("OK");
   }


   public static void main(String[] args) {
     MyClass obj = new MyClass();
     obj.method();

   }
}

Compiled from "MyClass.java"
class MyClass {
  MyClass();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public void method();
    Code:
       0: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #13                 // String OK
       5: invokevirtual #15                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return

  public static void main(java.lang.String[]);
    Code:
       0: new           #21                 // class MyClass
       3: dup
       4: invokespecial #23                 // Method "<init>":()V
       7: astore_1
       8: aload_1
       9: invokevirtual #24                 // Method method:()V
      12: return
}

Сложно судить о проблемах только по CPU.

Например если у тебя система, которая делатет рендеринг картинок или кодирует видео то она
обычно забирает столько CPU сколько есть в наличии.

Если у тебя event-like система, которая обслуживает события от бизнеса то ты можешь мерять
какие-то бизнес-метрики. Например - сколько сообщений в секунду система пропустила и на основании
этого делать выводы.

А очередь диска или загрузка ядер CPU в данной задаче не говорят ни о чем обычно. Может они - высокие
но бизнес чувствует себя нормально. А может быть 1 % CPU занят но база в блокировках и эта проблема не
видима со стороны системных метрик.

Если вы используете хранилище типа S3 то там есть опция - при сохранении файла (объекта в терминологии
S3), можно задать атрибут Time-To-Live

Вся прочая автоматизация - поверх обычных файловых систем требует чтоб был отдельный процесс
который по плану (раз в минуту например) удаляет все файлы по дате создания. Это cron, про который
выше уже сказали или это какой-нибудь quartz в парадигме Spring-Java-разработок например.

Не уверен что регулярки помогут. Но я-бы видел поиску нулей как-то такой интеграцией.

find . -name '*bills*' -exec is_file_contains_zeroes {} \;

здесь find - стандартная утилита а is_file_contains_zeroes вам напишет любой программист за 15 минут.

Но если битый винт содержал именно ДОКУМЕНТЫ то правильнее всего их искать именно валидатором
документов а не искателем нулей. Выше Adamos вобщем-то дал правильную линку на дубль этого вопроса.

Ну и на будущее чтоб не "бились винты" - делай бекапы. Потому что игры в восстановление - это не
production ready сценарий и за такие документы уже никто не даст цену. Грубо говоря они стали
мусором. Сомневаюсь что валидаторы закроют 100% сценариев разрушения.

Говорит нет такого сайта https://repo.implario.dev

Тут ничего не поделать. Доктор сказал - в морг.

Если у тебя будет 100 нод-получателей то полюбому хотя-бы одна из них будет недоступна в момент отправки.
Такова природа вещей. И не стоит требовать от сетей перфекционизма. Сети работают как погода. Как дождь
или снег. Надо это учитывать.

Поэтому брокер сообщений на базе Kafka или Apache Pulsar или Rabbit будет вполне себе реальным решением.

Ты пишешь про p2p. Но какой ценой этот p2p ты собираешся поддержать на продюсере? Ты создашь 100 сокетов
и 100 буферов отправки сообщений?

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

Очень похоже на шейпер со стороны провайдера. Попробуй понять как его обнулить.
Например закрой торрент клиент и посмотри чтоб все сокеты закрылись. А потом запусти
снова. Будет ли первоначальная картинка? Или там может шейпер сбрасывает по времени.
Через 5 минут. Через час.