Ну так и причем тут CAN?
Что изменится если заменить CAN на любые «внутренние провода»?
Переформулирую:
— невозможно «взломать CAN» также как нельзя взломать RS-232 или провода в розетке.
— но иногда можно взломать application уровень поверх CAN (или RS-232) и зависит это целиком от протоколов запущенного поверх CAN и их обработчиков.
«В этом виновата только Microsoft, нельзя вот так просто подрывать базу пользователей. Даже если у вас хорошая общая концепция и чёткое ви́дение, нельзя относиться к пользователям и разработчикам как к дерьму»
Да ну не было ни "хорошей общей концепции", ни "чёткого видения". Поэтому сначала убили 7, выпустив "новую концепцию 8", а потом еще раз убили 10-кой.
Неуправляемые природные процессы (ветер, освещенность, сток осадков) примерно хаотичны. Поэтому всегда будут периоды, когда наложение факторов/вероятностей приведет к существенной потери этих ресурсов (1-3 месяца штиль, облачность и без осадков). Гидро-генерация тут самая стабильная, поскольку у большинства ГЭС образуются водохранилища (большое накопление без потерь).
VFX1! В комплекте шло несколько игр, точно помню Heretic и Descent.
В первый заход я играл часа 4, причем последние пару часов в Descent. Естественно меня "укачало", да еще как! Снял шлем я только когда начало подташнивать, а еще минут через 5 началась жуткая морская болезнь. Пришлось прилечь, ходить и просто стоять я не мог. Поэтому очень хорошо запомнилось )
"… таблетка ядерного топлива весит всего 4,5 грамма, но по энергетическому эффекту эквивалентна 350 кг нефти или 400 кг угля.
При сжигании 1 кг каменного угля выделяется 7 кВт-ч энергии, 1 кг газа — 14 кВт-ч энергии. Из 1 кг урана при этом можно получить 620 тысяч кВт-ч энергии, то есть в 90 тысяч раз больше, чем при сжигании угля"…
D-Wave умеет только "квантовый отжиг", но не алгоритм Шора.
Ну то есть "на самом" деле "квантовый отжиг" (который работает и более-менее масштабируется) — это принципиально проще (до примитивизма) в сравнении с "универсальным квантовым вычислителем".
А для создания практически ценного "универсального квантового вычислителя" необходимо решить "проблему масштабирования", в отношении которой уместно процитировать wiki:
Чем больше кубитов находятся в связанном состоянии, тем менее стабильной является система. Для достижения «квантового превосходства» требуется компьютер со многими десятками связанных кубитов, работающими стабильно и с малым числом ошибок. Вопрос о том, до какой степени возможно масштабирование такого устройства (так называемая «Проблема масштабирования»), является предметом новой интенсивно развивающейся области — многочастичной квантовой механики. Центральным здесь является вопрос о природе декогерентности (точнее, о коллапсе волновой функции), который пока остаётся открытым.
На чем (IMHO) все и остановится примерно на 10^12 лет ;)
Это «вроде» я бы назвал одним из популярных заблуждений.
Ошибки можно корректировать ТОЛЬКО когда состояние зафиксировано, но не во время «расчетов». Любая проверка во время расчета означает что вы теряете суперпозицию, т.е. выходите из «квантового сумрака».
Поэтому «корректировка ошибок» возможно только как часть самого процесса/алгоритма вычислений. И вроде-бы «всё просто» — нужно только примерно удвоить кол-во кубит и связность между ними, а также быть готовым к тому, что результат отличный от незнаю/может_быть будет получаться в одном запуске из N^K^M, где N — кол-во кубитов, K-связи между ними, а M — кол-во «шагов» алгоритма…
Семантически нам нужно указать какие поля мы хотим обновить, а какие не трогать. В случае безсхемного JSON достаточно логично просто поместить в update-запрос только обновляемые поля с новыми значениями. Но возникают проблемы, если язык описания подразумевает наличия схемы (описание структур), из которого следует умолчание о null-значения у "отсутствующих" полей.
Выход достаточно стандартный = передавать в аргументах update-запроса не экземпляр структуры, а массив структур key-value. [ { name: "field1", vallue: null }, {name: "field2", vallue: "not a null"}, ...]. Конечно, так теряется контроль схемы на уровне языка, но это следствие недостатков языка (формы описания). Тем не менее, так недостатки формы (языка) не перерастают в проблемы API.
Проблема дизайна API тут в том, что семантика (смысл) запроса выражается с привязкой/зависимостью к неоднозначностям/недостаткам формы (языка описания запроса).
Это не отменяет недостатков JSON и/или GraphQL, т.е. действительно есть недостатки, в том числе в выразительности и удобства для тех или иных случаев. Но вдвойне неверно допускать протечки этих недостатков в API.
JS (и JSON как следствие), на мой взгляд, являются языками с массой недочетов/нелогичностей ради "упрощения и удобства", которые ведут к массе проблем. В свою очередь GraphQL идет следом по тем же граблям, с добавлением пары новых.
Если совсем кратко (и вынужденно высокопарно), то основная претензия в том, что предлагается замещение содержания формой представления информации, т.е. форма становится определяющей по отношению к содержанию.
Теперь мы наблюдаем, что попытки описать различные смыслы и "содержание запросов" этими языками, во многих случаях местами приводят к неоднозначности и прочей боли.
Покупать наш газ они «принципиально» не хотят (в данном контексте причины не важны).
Это кто вам такое сказал? Хотят и покупают. Они просто не хотят целиком зависеть от одного поставщика, поэтому покупают примерно одинаково у России, Норвегии и Голландии. Еще добавят в смесь туркменский и катарский. Причем потребление газа почти наверняка вырастет.
Вместо наращивания закупок более дешевого российского газа (и наращивания соответствующей инфраструктуры), проектируются и финансируются другие проекты. Конечно, логично не зависеть от одного поставщика, но объемов от других локальных поставщиков заведомо не хватает, а остальной газ дороже (даже туркменский, не говоря о катарском) и нет инфраструктуры для доставки (30 млд кубов через туркменский Восток-Запад — это очень мало). Короче, очевидно что не хотят.
Атома бояться и сами не умеют, опять-же не хотят у нас покупать технологию.
Вот те здрасте, а Siemens, который построил все немецкие АЭС и участвовал в строительстве наверно всех европейских АЭС, он чей? То что они не хотят заниматься строительством АЭС, не значит что они не могут.
Технология на новые (гораздо более чистые и безопасные) реакторы есть только у Ростатома. Такие реакторы Siemens не может, а старые (предыдущее поколение) они не хотят.
У Германии давным-давно/исторически проблемы из-за бурого угля (Brown coal), который дешевле, но при сжигании кратно (в расчете на теплоту) грязнее каменного угля (Hard coal) и несравнимо грязнее газа.
Каменного угля недостаточно, к тому же он дорог и таки коптит. Покупать наш газ они «принципиально» не хотят (в данном контексте причины не важны). Гидро-ресурсов нет. Атома бояться и сами не умеют, опять-же не хотят у нас покупать технологию.
Поэтому остается либо «дешевая» и как-бы «зеленая» энергия, либо еще больше копоти и кислотных туманов от бурого угля. Вот и морозят уши назло…
Ошибочка:
На самом деле промахов меньше
Что изменится если заменить CAN на любые «внутренние провода»?
Переформулирую:
— невозможно «взломать CAN» также как нельзя взломать RS-232 или провода в розетке.
— но иногда можно взломать application уровень поверх CAN (или RS-232) и зависит это целиком от протоколов запущенного поверх CAN и их обработчиков.
deniskin, а можно я вам еще в backlog наброшу?
— как пользователь я вижу кнопку "хочу перевод", которая в конечном счете ведет к формированию подобного задания на freelance.ru и/или где-то еще.
Блаж конечно, но хочется.
Да ну не было ни "хорошей общей концепции", ни "чёткого видения". Поэтому сначала убили 7, выпустив "новую концепцию 8", а потом еще раз убили 10-кой.
VFX1! В комплекте шло несколько игр, точно помню Heretic и Descent.
В первый заход я играл часа 4, причем последние пару часов в Descent. Естественно меня "укачало", да еще как! Снял шлем я только когда начало подташнивать, а еще минут через 5 началась жуткая морская болезнь. Пришлось прилечь, ходить и просто стоять я не мог. Поэтому очень хорошо запомнилось )
Почищено. Извиняюсь, промазал с тредом.
При сжигании 1 кг каменного угля выделяется 7 кВт-ч энергии, 1 кг газа — 14 кВт-ч энергии. Из 1 кг урана при этом можно получить 620 тысяч кВт-ч энергии, то есть в 90 тысяч раз больше, чем при сжигании угля"…
D-Wave умеет только "квантовый отжиг", но не алгоритм Шора.
Ну то есть "на самом" деле "квантовый отжиг" (который работает и более-менее масштабируется) — это принципиально проще (до примитивизма) в сравнении с "универсальным квантовым вычислителем".
А для создания практически ценного "универсального квантового вычислителя" необходимо решить "проблему масштабирования", в отношении которой уместно процитировать wiki:
На чем (IMHO) все и остановится примерно на 10^12 лет ;)
Ошибки можно корректировать ТОЛЬКО когда состояние зафиксировано, но не во время «расчетов». Любая проверка во время расчета означает что вы теряете суперпозицию, т.е. выходите из «квантового сумрака».
Поэтому «корректировка ошибок» возможно только как часть самого процесса/алгоритма вычислений. И вроде-бы «всё просто» — нужно только примерно удвоить кол-во кубит и связность между ними, а также быть готовым к тому, что результат отличный от незнаю/может_быть будет получаться в одном запуске из N^K^M, где N — кол-во кубитов, K-связи между ними, а M — кол-во «шагов» алгоритма…
Но это не точно :)
Ответ более-менее очевиден.
Семантически нам нужно указать какие поля мы хотим обновить, а какие не трогать. В случае безсхемного JSON достаточно логично просто поместить в update-запрос только обновляемые поля с новыми значениями. Но возникают проблемы, если язык описания подразумевает наличия схемы (описание структур), из которого следует умолчание о null-значения у "отсутствующих" полей.
Выход достаточно стандартный = передавать в аргументах update-запроса не экземпляр структуры, а массив структур key-value. [ { name: "field1", vallue: null }, {name: "field2", vallue: "not a null"}, ...]. Конечно, так теряется контроль схемы на уровне языка, но это следствие недостатков языка (формы описания). Тем не менее, так недостатки формы (языка) не перерастают в проблемы API.
Проблема дизайна API тут в том, что семантика (смысл) запроса выражается с привязкой/зависимостью к неоднозначностям/недостаткам формы (языка описания запроса).
Это не отменяет недостатков JSON и/или GraphQL, т.е. действительно есть недостатки, в том числе в выразительности и удобства для тех или иных случаев. Но вдвойне неверно допускать протечки этих недостатков в API.
JS (и JSON как следствие), на мой взгляд, являются языками с массой недочетов/нелогичностей ради "упрощения и удобства", которые ведут к массе проблем. В свою очередь GraphQL идет следом по тем же граблям, с добавлением пары новых.
Если совсем кратко (и вынужденно высокопарно), то основная претензия в том, что предлагается замещение содержания формой представления информации, т.е. форма становится определяющей по отношению к содержанию.
Теперь мы наблюдаем, что попытки описать различные смыслы и "содержание запросов" этими языками, во многих случаях местами приводят к неоднозначности и прочей боли.
Вместо наращивания закупок более дешевого российского газа (и наращивания соответствующей инфраструктуры), проектируются и финансируются другие проекты. Конечно, логично не зависеть от одного поставщика, но объемов от других локальных поставщиков заведомо не хватает, а остальной газ дороже (даже туркменский, не говоря о катарском) и нет инфраструктуры для доставки (30 млд кубов через туркменский Восток-Запад — это очень мало). Короче, очевидно что не хотят.
У Германии давным-давно/исторически проблемы из-за бурого угля (Brown coal), который дешевле, но при сжигании кратно (в расчете на теплоту) грязнее каменного угля (Hard coal) и несравнимо грязнее газа.
Каменного угля недостаточно, к тому же он дорог и таки коптит. Покупать наш газ они «принципиально» не хотят (в данном контексте причины не важны). Гидро-ресурсов нет. Атома бояться и сами не умеют, опять-же не хотят у нас покупать технологию.
Поэтому остается либо «дешевая» и как-бы «зеленая» энергия, либо еще больше копоти и кислотных туманов от бурого угля. Вот и морозят уши назло…