Просто что ток течет от + к - и все. Про землю уже после того, как ученик четко осознает, что ЛЭП заземлены через каждые N метров и ток через "землю" утекает обратно на электростанцию (а не просто "в землю").
Кто вообще придумал детям в школе рассказывать про "ток уходит в землю"? Мне эта формулировка испортила все восприятие процесса, я реально думал, что земля сама по себе способна магически вытягивать ток.
Про локальный запуск не совсем понял вопрос - в контексте разработке нужен отладчик, с голым docker-compose из run.sh отлаживать из VSCode не получится (наверно как-то можно через ssh, но это и будет эмуляция devcontainer). Конечно, в проекте обычно есть Makefile с build-docker, run-docker, test и т.п., но внутри devcontainer все это становится не нужно. Когда-то заморачивался с гибридными Makefile-ами, которые по разному выполняются в зависимости откуда запущен make. Ворох скриптов сокращается, но главное, что единожды все настроив и закоммитив в репо, другой разработчик с VScode и devcontainer, склонировав проект, поднимет все в два клика и сможет сразу приступить к работе.
Не упомянуто главное преимущество VSCode - расширение devcontainers. Выше жаловались про танцы с бубном в стиле vim, так вот с этим расширением и соответствующей папочкой в проекте, с правильно прописанными версиями и зависимостями, все сводиться к двум кликам. Типичная ситуация на проекте - коллеги пару дней тратят на запуск сложного проекта в Idea, тогда как в Vscode с devcontainers уже вовсю идет активная разработка. Из недостатков - не поддерживаются некоторые экзотические связки вроде rancher + arm mac, но в классике linux + docker все стабильно.
Вот производительность как раз и получается кошмарная Я про это, что было сказано вами в контексте "кошмарной x86 архитектуры" - будут хоть какие-то пруфы? Я вам привел бенчи где АМД отказалась от "красивой" архитектуры в пользу "ужасной" в 90х. Спустя 30 лет мы все там же, в задачах, требующих производительность, все те же "бредовые и ужасные" х86, вот только недавно Амазон стал пропихивать свои гравитоны, но о их внутренней "красоте" стоит только догадываться.
Я сравниваю отвратительный CISC (IA-32) с хорошими CISCами (PDP-11, VAX-11, System/360,370...z/Architecture). Реальные результаты сравнения процессоров из разных эпох оставляю на вашей совести.
Расширение адресного пространства это само собой, но для этого не было нужды использовать сегментную модель, можно было просто усовершенствовать существующую flat модель из 8080. Почему этого не сделали я написал в предыдущем ответе. По поводу декодирования команд - так оно не для человека, а для железа, у железа несколько другой взгляд на красивость структуры, там важнее производительность и экономия ресурсов.
В 8080, разработанной в 70-х, у них не было сегментной модели памяти, никаких граблей они не добавляли. Добавление сегментных регистров в 8086 и 80286 обусловлено, в первую очередь, необходимостью запускать доминирующую тогда в корпоративной среде CP/M на 8086 (фактически эмулируя 8080, для которой эта ОС разрабатывалась) с минимальными тратами на уровне аппаратных ресурсов, это был, по-сути, вынужденный шаг.
В google photos есть опция экспорта всех фотографий в архив, с последующим заливом в холодное хранилище в нескольких гео-зонах. Такое может пропасть только если не станет самого гугла.
А куда они по вашему денутся?
Да нет же, земля просто играет роль проводника, а разность потенциалов возникает на источнике где-то на электростанции.
Просто что ток течет от + к - и все. Про землю уже после того, как ученик четко осознает, что ЛЭП заземлены через каждые N метров и ток через "землю" утекает обратно на электростанцию (а не просто "в землю").
Кто вообще придумал детям в школе рассказывать про "ток уходит в землю"? Мне эта формулировка испортила все восприятие процесса, я реально думал, что земля сама по себе способна магически вытягивать ток.
Про локальный запуск не совсем понял вопрос - в контексте разработке нужен отладчик, с голым docker-compose из run.sh отлаживать из VSCode не получится (наверно как-то можно через ssh, но это и будет эмуляция devcontainer). Конечно, в проекте обычно есть Makefile с build-docker, run-docker, test и т.п., но внутри devcontainer все это становится не нужно. Когда-то заморачивался с гибридными Makefile-ами, которые по разному выполняются в зависимости откуда запущен make.
Ворох скриптов сокращается, но главное, что единожды все настроив и закоммитив в репо, другой разработчик с VScode и devcontainer, склонировав проект, поднимет все в два клика и сможет сразу приступить к работе.
Хм, интересно, у них вроде была только своя, cloud-based, ну значит IDEA теперь дотянулся до VSCode в этом плане.
В расширении gitlens имеется интерактивный rebase
Не упомянуто главное преимущество VSCode - расширение devcontainers. Выше жаловались про танцы с бубном в стиле vim, так вот с этим расширением и соответствующей папочкой в проекте, с правильно прописанными версиями и зависимостями, все сводиться к двум кликам. Типичная ситуация на проекте - коллеги пару дней тратят на запуск сложного проекта в Idea, тогда как в Vscode с devcontainers уже вовсю идет активная разработка.
Из недостатков - не поддерживаются некоторые экзотические связки вроде rancher + arm mac, но в классике linux + docker все стабильно.
Времени на раскачку больше нет!
Поможет ли табличная замена оптимизировать следующую простую функцию:
https://github.com/GStreamer/gst-plugins-base/blob/ce937bcb21412d7b3539a2da0509cc96260562f8/gst-libs/gst/video/video-converter.c#L1190
Как это эффективнее всего переписать используя AVX-регистры?
Плоть, Север, мера, срок, необходимость
ИИ действительно каким-то боком относится к хаосу, турбулентности, эффекту бабочки и вот этому всему?
Может есть какие пруфы по производительности? у меня вот есть такой: https://web.archive.org/web/20000304083834/http://www.amd-embedded.com/Benchmarks/whyx86.htm. Из них можно понять, почему AMD похерило RISC линейку в пользу x86 в 90-х.
Расширение адресного пространства это само собой, но для этого не было нужды использовать сегментную модель, можно было просто усовершенствовать существующую flat модель из 8080. Почему этого не сделали я написал в предыдущем ответе. По поводу декодирования команд - так оно не для человека, а для железа, у железа несколько другой взгляд на красивость структуры, там важнее производительность и экономия ресурсов.
В 8080, разработанной в 70-х, у них не было сегментной модели памяти, никаких граблей они не добавляли. Добавление сегментных регистров в 8086 и 80286 обусловлено, в первую очередь, необходимостью запускать доминирующую тогда в корпоративной среде CP/M на 8086 (фактически эмулируя 8080, для которой эта ОС разрабатывалась) с минимальными тратами на уровне аппаратных ресурсов, это был, по-сути, вынужденный шаг.
Это не бред, а обратная совместимость. То, что, не в последнюю очередь, позволило данной архитектуре завоевать рынок в 80х.
В google photos есть опция экспорта всех фотографий в архив, с последующим заливом в холодное хранилище в нескольких гео-зонах. Такое может пропасть только если не станет самого гугла.
Если б только тупые, многие еще и агрессивные, оттого и воевать лезут...