VoidVolker

Тебе не надо всё из списка устанавливать.
1. Ставишь Visual Studio 2022 preview
https://learn.microsoft.com/en-us/visualstudio/rel...
2. Ставишь .NET 8 Visual Studio SDK x64
https://dotnet.microsoft.com/en-us/download/dotnet...

Всё.

Ну и это ещё preview. Даже не rc => тебе должно хватить консольного sdk и vs code, если только попробовать.

Не трогай. Они все нужные.

Главное смотри, чтобы у системных не было login shell
Например ок, если /usr/sbin/nologin или /bin/false

mark:x:1001:1001:mark,,,:/home/mark:/bin/bash
[--] - [--] [--] [-----] [--------] [--------]
|    |   |    |     |         |        |
|    |   |    |     |         |        +-> 7. Login shell
|    |   |    |     |         +----------> 6. Home directory
|    |   |    |     +--------------------> 5. GECOS
|    |   |    +--------------------------> 4. GID
|    |   +-------------------------------> 3. UID
|    +-----------------------------------> 2. Password
+----------------------------------------> 1. Username

Никак. Ценностная составляющая сайта должна быть сосредоточена на серверной стороне. Клиентская часть может быть сфотографирована, разобрана до винтиков для каких угодно целей пользователем сайта, если он имеет к ней доступ.

Никак — скриншот делает не браузер.

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

В print все аргументы, следующие за первым аргументом, будут добавлены к первому аргументу как единая строка с разделителем пробелом. Однако в input пробел автоматически не добавляется.

Добавляйте пробел когда вам нужно. e.g 'string ' + '1'.

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

arr.filter(obj => !obj.status).length;
arr.reduce((length, {status}) => status ? length : length + 1, 0);
...и т.п.

Да, нужно перевести скорость в радианы. Так, чтобы 0 было pi/2 радиан (направление вверх), а -200 - это 4/3pi. И радианы при увеличении скорости уменьшаются.

Поскольку все линейно, то фрмула такая: alpha = pi/2 - speed*5/1200.0

Что такое angleValueTransformer я не знаю, но если ему задаются отрезки углов и значений, которые оно линейно преобразует в друг друга, то углы должны быть от 240 до -60, что соответствует скоростям от -200 до 200. Ну, или углы от 4/3pi до -pi/3, если вы значение сразу в синусы/косинусы передаете, не переводя из градусов в радианы.

И, кстати, развертка будет не 310, а 300 градусов от -200 до 200. Иначе скорость 0 не будет вертикально вверх.

Можно

что то вы гоните

https://api.jquery.com/position/

.position()

Description: Get the current coordinates of the first element in the set of matched elements, relative to the offset parent.

Проверять работу оперативки из-под Windows (да и любой другой ОС) - не самое лучшее решение. Проверьте через Memtest86+, причём в длительном режиме, часов 12.

Вопрос задан как пальцем в небо.
Быстрее будет не отдельно взятый постгрес или сайт на js, а машина, на которой это все будет считаться.
JS где - у пользователя в браузе, или это nodejs на сервере?
постгрес крутится на той же машине, или на другой? Какой там процессор, сколько, сколько памяти?

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

Но вам никто не ответит на вопрос точно. Гораздо проще провести перформанс тесты и посмотреть живые ответы.

Вопрос в объемах данных.

Если вы хотите найти средний чек по сотне покупок - то вообще без разницы, как именно вы это сделаете.
А если у вас средний чек по сотне тысяч покупок - то считать на nodejs будет довольно проблемно, даже если вы туда никакой ORM-ки не накинете над данными.

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

Мужские мужчины уже ответили на основной вопрос.

Я добавлю что чем больше данных мы обрабатываем тем дороже становиться цена передчи
информации из места где оно храниться в блок вычислений. В концепции трехзвенки которая
описана RDS(Postgres)/NodeJS/Python/Web удобнее всего вычилсять прямо в Postgres. Поскольку
данные рядом и сетевых расходов на передачу нет. Если Postgres по каким-то причинам не может
вычислять или не владеет API то в этом случае мы с помощью курсора (SELECT) передаем
нужный датасет на клиента (в данном случае это Python/Node) и там вычисляем. При этом
мы должны понимать что это займет время и сетевой канал да еще и результат вычислений
тоже надо отослать обратно. Тоесть данные будут бегать как рейсовый автобус туда-сюда.

Для однозначного решения что хорошо и что плохо - надо ставить эскперимент. Но предварительно
мне и присуствующим уже очевидно что лучше всего вычислять прямо в хранимых процедурах
Postgres. Единственным доводом против может быть несовершенство языка PL/pgSQL
но я-бы этот факт тоже проверил. Для реляционных задач его обычно хватало.

Данная проблема (рейсовый автобус для данных) еще более сильно выражена в BigData. Там стараются
дизайнить систему так что данные - write-only и после загрузки в хранилище (ETL/ELT) больше никогда
не изменяются и лежат неподвижно (т.н. Bronze Level информации). И джобы которые бегают
по ним - запускаются в вычислительном кластере физически рядом с дисковым хранилищем.

Вот. А на клиента отдаются обычно сводные отчеты и кака-то аналитика. Это то что в 100-10000 раз меньше
по размеру обычно чем основные данные.

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

это называется OLAP
OLAP DB так и гуглите, есть как надстройки на классик RDBMS так и спроектированные базы

есть конечно и продукты на Питоне но это больше для развлечения, основная проблема - засирание памяти

В общем, чтобы не издеваться над девушкой, объясним на пальцах.

Во-первых, заголовок у вопроса чудовищно некорректный. Это все равно что спросить, "что быстрее - пылесос или стиральная машина?"
Во-вторых, ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там" совершенно очевиден: обработку данных следует производить в общем случае только в БД. Она для этого и придумана. Чтобы обрабатывать значительные объемы данных.

Да, js тоже "может" обрабатывать большие объемы данных.
Но чтобы значительный объем данных обработать, его сначала надо передать, полностью забив канал между сайтом и базой
Чтобы значительный объем данных обработать, его надо сначала проиндексировать. Причем делать это каждый раз, а не использовать уже имеющийся набор индексов
Чтобы значительный объем данных обработать, надо иметь значительный объем памяти или упасть из-за её недостатка
Чтобы значительный объем данных обработать в многопоточном режиме (а сайт как раз является многопоточной системой), все вышеперечисленное надо умножить на количество посетителей сайта - при каждом запросе перегонять весь массив данных, выделять память, индексировать, считать. Если же вы оставляете все данные в памяти приложения, то их тогда надо как-то синхронизировать с БД. То есть вы себе собираете кучу проблем на пустом месте.

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