Wan-Derer

Чтобы небыло таких проблем, нужно разграничивать хранение данных и их отображение. Можно изобрести свой велосипед, можно использовать классические решения, например такие как MVP, MVC (Model-View-Controller загуглите).
Основная идея заключается в том, что у вас существует объект (модель), который хранит данные, а все формы (вью), в которых эти данные отображаются, берут их именно из этого объекта. При изменении в одной из форм, данные меняются в объекте и другие формы тут-же обновляют свою информацию (за корректностью этого следит презентер или контроллер).

Принуждает ли Apple использовать AppleID?

Можно не использовать, но так же будет не доступен магазин приложений, синхронизация файлов и паролей, контакты, facetime звонки, функция findmymac. Вообщем все что завязано на облако, но система будет работать полноценно и приложения можно устанавливать скачивая dmg (аналог exe или msi от windows). Так же есть brew, аналог linux репозитория для открытого софта.

Есть ли, например, реклама сервисов Apple в Finder?

нет

Слышал, что настольная ОС от Apple переняла достаточно от мобильной.

Да они идут к унификации интерфейса. Последние планшеты так же используют процессор m1 и при подключении внешнего экрана система становиться очень похоже на десктопную. Рано или поздно они сравняются. Windows делает тоже самое т.к. есть куча ноутов трансформеров с сенсорными экранами.

Когда при первом подключению к сети без каких-либо действий с моей стороны автоматически из магазина загрузились Яндекс Музыка, Minecraft и Candy Crush,

Если не подвязывать учетку icloud, то ничего не будет.

Какие известные проблемы на данный момент имеют актуальные машины от Apple?

- не стоит брать менее 16GB RAM т.к. это влияет на износ SSD
- выбирать модели с 512GB SSD и выше, т.к. они быстрее
- если планируешь нагружать, то рассматривай модели с куллером

Меня смущает "одноразовость" - по сути распаяно вообще всё

Умельцы уже научили паять RAM и SSD на новых mac. Батарейка пока не распаяна.

1. Делаете рабочий прототип.
2. Патентуете его.
3. Создаете профиль проекта на площадки для краудфандинга для сбора средств.
4. Если набирается средств хотя бы на десяток единиц продукции - делаете их и отправляете вложившимся в проект.
5. Собираете статистику сбора средств, реализации прототипов, отзывов, пожеланий в документальном виде, и предлагаете крупной компании купить вас.

вижу две цели.
1. иногда статистика сайта публикуется (например, через webalizer). Ссылка может быть неприметная, юзеры на нее не заходят, но, бывает, что поисковик до нее добирается. Соответственно, с какждого такого атакованного сайта будут нужные ссылки на помойку.
2. админ (вы) сам может перейти (да, не каждый, но "пять старушек - рубль", они, возможно, все .ru или .com сайты так заспамливают). Будет очень качественный переход (разные подсети, разные браузеры, ОС) и какая-то реферральная ссылка может сработает.

Коротко нет:
Обработчики jpg/pdf на телефонах кастрированы поэтому эксплоиты для pdf не действуют

Более развернуто:
У мобильных телефонов более продуманная система безопасности и они не делались такими универсальными как компьютеры, поэтому сложнее выполнить что то.

Но булки расслаблять не стоит:
Вам могут послать эмодзи и превратить ваш мобильник в кирпич, ну или вот это https://www.gazeta.ru/tech/news/2023/06/22/2072034...

Вопрос неконкретный, и однозначный ответ на него невозможен, т.к. есть уже 17 версий iOS для телефона, а сабверсий сотни, да еще на разных железках. Возможно, какую-то версию при каких-то особых условиях в каком-то смысле удастся «заразить». А может и нет.

Но в общем случае - нельзя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://medium.com/@dan_abramov/making-sense-of-re...
Заметка от Дена Абрамова.
Есть очень редкие кейсы, которые пока невозможно реализовать функциональными компонентами и хуками, они описаны в документации, в остальных случаях советую предпочесть функциональные компоненты и хуки. "Углубляться" нужно в оба подхода, все углубление состоит в том, что ты хорошо должен знать жизненный цикл компонентов, при чем депрекейтед тоже, хотябы чтобы уметь отрефакторить старый код, но если ты пишешь новый компонет - пиши его в функциональном стиле.