mayton2019

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

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

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

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

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

Но если между приложением и сокетами у тебя стоит нечто (например SOAP) то тогда обсуждать этот
вопрос становится более интересно.

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

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

Никто этим не занимается. В современном мире есть 100500 способов виртуализации Python
библиотек. Виртуалки, Докеры, Кубернетисы, И всякие анаконды, конды и прочее что можно
в командной строке делать просто меняя PATH.

Во всех случаях мы описали тип слева. Тоесть задача типизации - выполнена.

float a = 1.0f;
unsigned int a = 10u;

Я думаю что ничего дополнительно указывать не надо. В противном случае у code-reviewer
это вызывает удивление и очередной WTF. Тоесть вам придется объяснять своему коллеге
ДЛЯ ЧЕГО вы ввели в исходные код дополнительную информацию.

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

Вообще после ковида ситуация для людей с особеностями - улучшилась. Бизнес потихоньку научился
работать с удаленкой. Я даже думаю что те специальности которые раньше были ТОЛЬКО офисные
(бухгалтерия) сейчас тоже научились удаленке.

Вот в один поток на сях. Только сам скомпилируй. 32 млн строк в секунду. Если писать в /dev/null

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

// habr.com : mayton2019 - 3 Sep 2023

char *hex = "0123456789abcdef";
char *buf;

void streamer(int max_depth, int level, char *alphabet, int alphabet_size) {
   for(int i = 0 ; i < alphabet_size ; i++) {
      buf[level] = alphabet[i];   
      if ( level < max_depth ) {
        streamer(max_depth, level+1, alphabet, alphabet_size);
      } else {
        buf[level] = '\0';
        printf("%s\n", buf);
        break;
      }
   }
}

int main(int argc, char** argv) {
  buf = malloc(strlen(hex) + 1);
  streamer(16, 0, hex, strlen(hex));
  free(buf);
  return 0;
}

Вот как я мерял.

gcc hex-gen.c -o hex-gen.exe && ./hex-gen.exe | pv -l -r > /dev/null
[30.7M/s]
[30.1M/s]
[30.3M/s]

Вот если писать в текстовый файл то скорость чуть медленнее. 24 млн строк за секунду.

Вот. Проверяй данные. Что я нигде не ошибся.

UPD: Лишний ноль убрал.
UPD: +break добавил.

Я слегка читернул и спросил всезнающего искусственного всезнайку. Вот что он ответил кратко:

1. Open the 3DS File
2. Export as FBX or OBJ
3. Import into Blender

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

Бери сведенья с телеграм канала напрямую.

Иметь возможность запускать игры, пока другой работает на этом компе?

В офисе я-бы не советовал этого делать. Коллега все равно почувствует
легкое неудобство. А зачем ему это надо? И себя подставляете.

Я пока студент, перешёл на второй курс.

Тебя в любом случае градуируют как junior/trainee на первой работе.
И дело даже не в том сколько олимпиад ты прошел и сколько ты книжек прочитал.
Просто звездочки в погонах надо заслужить. Если ты талантлив - то наверное
за год перепрыгнешь уровнеь junior но я советую вообще с этим не спешить.

Нет ничего хуже самозванца. Согласен?

Вот привык я к ШИНДОВС, а в ней программы устанавливаются через *.msi или *.exe файлы.

Да ты - старый дед! :) Все админы и девопсы при использовании Windows ставят себе пакеты через
"шоколядку" (chocolatey) https://chocolatey.org/

Вот как я себе ставил поддержку zip в консоли

PS C:\Windows\system32> choco install zip
Chocolatey v2.2.2
Installing the following packages:
zip
By installing, you accept licenses for the packages.
Progress: Downloading zip 3.0... 100%

zip v3.0.0 [Approved]
zip package files install completed. Performing other installation steps.

Вот привык я к ШИНДОВС...

Я кстати очень не одобряю твою культурную апроприацию к Linux-сообществу (ЛОР и прочее). Только
они имеют моральное право говорить Маздай, Шишдовс и так далее. А ты - типичный
виндузятник.

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

Ты-же для игр покупал? Обычно опытные геймеры примерно на глаз видят скорость кадров и продергивания
при запуске своей игры. Или запусти тест. Раньше был 3D-Mark. Щас не знаю что но тоже наверное что-то
есть подобное для индекса производительности игр.

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

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

P.S. Покупал с рук... сам знал риски. Вернись туда с битой. Разнеси там все ... :)

В феврале всегда 28 дней. Использую datetime.

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

Не пойму зачем тебе накое надо.

Технически - можно. Но MongoDb оптимизирована для хранения документов. И если вместо документов
туда складывать фильмы то может оказаться так что вы платите очень много за такие блобы которые
выгоднее держать на файловой системе или на сторедже. Привету пример. Если вы храните
документ в котором десяток текстовых полей и 11 поле - это блоб с фильмом длиной 1.5Гб то
получается что реально полезная для поиска и индексирования информация составляет
менее 1% (!) от общего размера БД. А все остальное - это балласт. Я как бывший базовик
привык что в таблицах БД лежит только полезная и нужная для SELECT ... WHERE информация.
Если эта информация не полезна для поиска - то ей не место в БД.

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

Я не специалист конкретно по Монге но вот тут пишут о реализациях хранения блобов https://www.mongodb.com/developer/products/mongodb...

Почитайте.

У меня был комп Электроника БК1001 и ZXSpectrum которые работали на частотах 3 и 3.5 Мгц и никаких
проблем я не испытывал.

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

Прикладной код, при работе на низких частотах может видеть некоторые аномалии при работе с датой-временем
но это вообще не проблема процессора - а это проблема вашего прикладного кода. Тоесть вы должны были
писать код таким образом что даже припаркованный VMWare не должен крашить вашу бизне логику только
потому что часы резко прыгнули вперед на несколько суток например.

Других проблем вобщем-то не предвидится.