mayton2019

Если носитель информации - ненадежный - то к нему добавляют дополнительные коды типа Хэмминга которые восстанавливают поврежденные биты после сбоя. На 99% нормальных носителей это реализовано аппаратно. Если твоя флешка сбоит или не очень надежна то желательно купить новую. Если ты всё таки хочешь наковырять золота в навозе - посмотри в сторону утилиты par2 manpages.org/par2 она на десяток процентов увеличит размер твоих бэкапов но будет гарантировать фиксацию нескольких бит если такое будет. Она работает поверх обычной файловой системы и ее коды контроля будут просто дополнительными файлами рядышком.

А проверить восстановистя ли бэкап в принципе - невозможно. Как в той философской мысли - нельзя узнать какой пудинг пока ты его не съел. Поэтому и гарантировать целосность бэкапа на логическом уровне можно только проведя симуляцию его полного восстановления в БД.

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

Интересный вопрос. Кмк форд-фалкерсон либо плохо параллелится. Либо после параллелизма просядет в блокировках вершин и ребер, что сделает его худшим по эффективности чем непараллельный.

Тут надо подумать.

Изучение Go, Rust я поддерживаю. Это развитие. Это хорошо.

Во фриланс особо не рвись. Я за свою жизнь не видел качественных продуктов в основе которых стоял бы фриланс.

Информатика и вычислительная техника и ЭВМ это немного архаичное название современных it наук таких как собственно программирование, FP, GA, NN, MV.

Старые слова можно много где встретить в старых книгах. У того же Дональда Кнута есть отсылки к алгоритмам сортировки на магнитных лентах.

Идея выглядит очень рискованной.

Несколько важных поинтов. Во первых у автора - путаница в голове. RSA относится не к шифрующим а к подписывающим и проверяющим алгоритмам. В учебных книжках описывают юзкейс как Алиса передает сообщение Бобу но это просто учебный пример. В реальных протоколах типа SSL работает бутерброд из двух технологий. Первое - это процесс рукопожатия автентификации где выясняется кто есть кто. Здесь может быть RSA. И обмен сеансовыми ключиками для симметрички. И второе - это открытие симметричного шифрованного канала где уже работает другой алгоритм типа AES/Blowfish.

И второй поинт. Зачем. Если просто разработать систему - то надо брать готовое под Питон. Если надо разбираться - то продуктовые шифры и алгоритмы очень сложны. Можете просидеть много месяцев. Остановитесь на учебных максимом до DES.

Автор очень быстро отбросил Postgres. Но я хочу спросить были ли исследованы все возможности? Например TimescaleDb.

Вопрос в том как прикладывать линейку. Автора будет интересовать Декартово расстояние? Или расстояние Манхеттена?

Полностью согласен с ораторами насчет виртуализации.

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

Нужно 100% собрать логи и посмертные снимки памяти приложений. Или приложения. Скорее всего оно одно. И оно-же является источником проблемы. Это приложение надо перенести в докер к лимитами по памяти и там запускать.

Дампы памяти надо проанализировать и понять что флудит. С точки зрения приложения должны быть какие-то гарантии или требования по штатному режиму работы. Тоесть если ему надо 8Г то дайте ему ровно 8 и не больше.

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

Давайте сразу самую хардкорную постановку. Изображение было скейлировано. Тоест по-пиксельное сравнение вам ничего не даст. Нужно что-то более умное.

База данных в таких случаях не подходит. Она не умеет индексировать "по ключевым словам". И выражения с LIKE обычно дают плохие планы выполнения т.к. искомое стоит в середине строки. Классический базёвый индекс в таких случаях не работает. Можно поробовать оффлайновый индекс по товарам с использованием Apache Lucene. Но это потребует определённых усилий по подготовке и актуализации такого индекса. Грубо говоря его надо постоянно синхронизировать по новым товарам.

На базе стандартного файлового API скорее всего невозможно. Объясню почему. Linux оперирует файловым API на уровне команд open/close/seek/read/write. Это основа которая работает для всех файловых систем. Если опуститься на уровень какой-то специфичной файловой системы (например vfat) то можно наверное порезать файл на кусочки кратные размеру блока файловой системы без пере-аллокаций. Но это - грязный хак который будет работать только под root и только для specific файловой системы. И только для особых условий (граница блока). Вобщем технически это сделать можно но использование этой утилиты будет носить "разрушительный" характер наподобие утилит parted, fdisk, mkfs.* и прочих. Сильно сомневаюсь что такая утилита будет полезна и востребована. Лучше пользоваться нормальным API.

Делаешь - правильно. Гугли по ключевому слову WebSockets. И все фреймворки что с этим связаны.

grep -v оставляет весь текст кроме указанного шаблона.

Такой IDE не существует. И не будет существовать. Объясню почему. В инфо-технологиях существует класс задач которые нельзя решить "просматривая глазами код". Например нельзя доказать что код обладает каким-то свойством. Например свойством что он остановится с гарантией после 100000 итераций. Чтобы такое доказать надо этот код скомпилировать и запустить. Грубо говоря рантайм или собственно работа кода является доказательством его правоты. И никакие статические анализаторы не способны глянуть глубже чем рантайм.

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

Еще альтернативный вариант - просмотр кода человеком. Это работает. Иногда.

Статические анализаторы могут просто подсказать какую-то простую ошибку типа потенциальный NPE или выход за границы массива. Но только в очень простых кейсах.

В книге Холдена Карау - "Изучаем Spark" - глава 9 Spark SQL этому вопросу уделелено 1-2 странички. Можно почитать.

Кешировать "каким-то образом" можно "всё что угодно". Redis и прочие коробочные решения для кешей - работают
но они к технологии Spark не имеют никакого отношения. Собственно их можно советовать как универсальный
совет для любых систем которые имеют back-end. Интеграция их же со спарком это вообще отдельный вопрос.