Конкретно в этом случае интересно то, что снимали на обычную зеркальную камеру
Да можно и на мыльницу снять, если выдержку достаточную поставить, и наловить фотонов во всё тот же пиксель матрицы. Даже если атом там не один, или его мотыляет полем туда-сюда) Картинка не изменится.
Я к тому, что полноценным фото атома можно считать такое, на котором понятно, что это действительно один атом. В данном случае пиксель фотоаппарата соответствует огромной области, наверное миллионов атомов, и что это фото одного, да ещё и конкретного, а не другого - можно только поверить на слово.
Формально, это не фото атома, а регистрация света, рассеянного на электронах одного атома.Было бы там не один атом а два, десять, тысяча - фото было бы точно таким же :)
С этим есть проблемы, если по простому - то должен быть на том же участке потребитель, который примет выработанную энергию
Так ведь обычно на маршруте не один состав едет. Возврат энергии в сеть просто приводит к уменьшению потребления из сети другими составами. Чтобы "спалить ТП", нужно совпадение, когда (почти) все составы одновременно тормозят, и (почти) нет разгоняющихся. То есть, грубо говоря, суммарное потребление всех составов на линии вдруг оказывается ниже их суммарной генерации. С учётом, что рекуперация как правило даёт лишь около половины энергии, затраченной на разгон, вероятность этого не высока при более чем двух-трёх составах на одном участке тока.
Весь проект надеялся, что будет как в проекте с ДНК человека. Где должны были работать миллиарды человеко часов, а потом пришёл один чел и проанализировал всю ДНК в одно лицо за короткое время.
Забыл вам про это ответить сразу, отвечаю отдельным постом. Вы, вероятно, о ПЦР, изобретённой Кэрри Муллисом. Эта реакция позволила значительно увеличить скорость перевода генетической информации из физической структуры в AGTC последовательность, которую мы уже можем записать хоть на бумаге хоть в компьютерной программе. Однако, наличие AGTC последовательности не означает, что мы сразу её понимаем. Это как умение читать иероглифы - научиться отличать один от другого не проблема. Проблема в том, чтобы понимать смысл написанного ими. И ПЦР в общем-то не сильно нас продвинула в понимании ДНК кода. Он просто научил нас быстро его читать.
Все эти истории "получили системный промт" вызывают у меня один вопрос - а откуда уверенность, что это и есть "заложенный в систему разработчиками промт", а не выхлоп бредогенератора, который пытается соорудить юзеру что-то похожее на то, что он хочет?
Если задачу извлечения промта повторить несколько раз, с разных аккаунтов, с разной историей взаимодействия - насколько разными будут получены эти "системные промты"? Сколько процентов в них будет совпадать?
Несмотря на все усилия, скорость копирования коннектома была низкой.
Какое это имеет отношение к симуляции?
По-моему, вы думаете что симуляция работы мозга компьютером примерно то же самое, что симуляция работы процессора другим процессором. Но это совсем другое!
При создании симулятора процессора процессором, мы просто переводим инструкции с одного языка на другой. Это примерно как переводить с английского на японский - несмотря на различный алфавит, это не сложно. Но при этом симуляция происходит не на уровне скажем транзисторов, а на уровне языка инструкций. Поэтому, например, инструкция А на реальном процессоре занимает 6 тактов, а инструкция Б 12 тактов, а в симулированном процессоре - обе по 8 тактов, если не предпринять специально задержек, которые замедлят симуляцию, но соблюдят задержки.
А теперь представьте себе, что нужно перевести с английского на язык жестов. Как? Просто программы уже мало - нужно видеокамеру для "ввода" жестов собеседника и как минимум экран показывающий видеоряд жестов ему в ответ, причём это, конечно же, не то же самое что настоящие жесты рук.
Точно так же обстоит дело с симуляцией мозга. Если вы симулируете нейроны как чёрный ящик внутри которого ничего не происходит в физическим смысле, лишь матричное перемножение с какими-то весами - вы не получите действительно аналогию работы настоящего мозга, это будет довольно примитивная имитация. И её примитивность не позволит вам ни исследовать мышление, ни разрабатывать лекарства от альцгеймера или шизофрении, ни изучать восстановление после инсульта - короче ничего реально полезного. Ничего из того, что было заявлено как цель проекта симуляции мозга.
А как достичь симуляции на уровне, который позволит этого? Что, симулировать настоящую химию всех этих нейромедиаторов, цикл Кребса, эмулировать взаимодействие молекул? А пупок не развяжется от моделирования взаимодействия 10 в 25 степени молекул?
The Blue Brain Project was a Swiss brain research initiative that aimed to create a digital reconstruction of the mouse brain. The project was founded in May 2005
The Human Brain Project (HBP) was a €1-billion EU scientific research project that ran for ten years from 2013 to 2023.
Human Brain Project (HBP) – флагманский проект ЕС (2013–2023) – изначально ставил очень амбициозные задачи. По формулировке 2012 года, целью было «заложить техническую основу для новой модели ИКТ-исследований мозга, способствовать интеграции данных и знаний из разных дисциплин и объединённым усилиям сообщества достичь нового понимания мозга, новых методов лечения его заболеваний и новых мозгоподобных вычислительных технологий»
Со временем акценты HBP эволюционировали. Уже к середине проекта проект сменил часть руководства и расширил упор с одного лишь моделирования мозга на создание цифровой инфраструктуры и инструментов («цифровой нейронауки»). В частности, в 2019–2021 гг. была официально запущена платформа EBRAINS, а внимание сместилось на предоставление учёным данных, атласов и вычислительных ресурсов.
В заключительной фазе (2020–2023) HBP концентрировался на трёх научных направлениях (сетевые модели мозга, сознание и искусственные нейронные сети) и на развитии сервисов EBRAINS.
Несмотря на успехи, ряд первоначальных целей HBP остался не достигнутым или выполненным лишь частично. В первую очередь это касается полной симуляции всего мозга и полного «понимания» его работы. Уже на старте многие эксперты указывали, что задача смоделировать в деталях полный человеческий мозг за 10 лет настолько амбициозна, что близка к нереальной. Итоговые отчёты признают, что HBP так и не реализовал цель симуляции всего мозга: «проект не достиг своей цели по моделированию всего человеческого мозга – цель, которую многие учёные считали слишком амбициозной».
Кроме того, некоторые научные задачи были переоценены или изменены в ходе проекта. Например, формально HBP предполагал «новое понимание сознания», однако к 2023 г. эта цель осталась нерешённой: моделирование сознания по-прежнему считается «за гранью».
Аналогично новые лекарства от болезни Альцгеймера или шизофрении непосредственно не появились; ключевые прорывы в лечении состоят лишь в создании инструментов для планирования операций и диагностики. В отчёте эксперты отмечают, что HBP «приблизил нейронауку к новым клиническим и промышленным применениям», но основные медицинские цели находятся на «начальных этапах».
Представители проекта считают, что был реализован «изменившийся» подход к нейронауке, и рады, что «наши усилия удалось признать со стороны». В то же время в научном сообществе HBP подвергался критике, особенно в середине проекта, за излишний оптимизм целей и управленческие сложности. Так, независимые обозреватели указывали на «несовместимость» заявленных амбиций с ресурсами проекта: «HBP не достиг цели по симуляции всего мозга… проект изменил направление несколько раз и стал выглядеть фрагментарным»
Таким образом, задача симуляции мозга на текущем нашем техническом уровне всё ещё невозможна.
Да и модульный монолит вполне можно пилить человек в 5 только бэков, например, если в разных углах пилить.
Ага, но вскоре начинаются проблемы совместимости разных третьесторонних модулей, потому что Вася использует приблуду завязанную через зависимости на некий плагин энной ветки, а Петя ветки эн плюс эм, и в зависимости от версии, впиленной в монолит, не работает либо Петин код, либо Васин :)
Или другой вариант - скажем, код Пети работает на nodejs v.18 и ниже, а код Васи не может работать ниже чем на nodejs v.20, и либо Пете надо переписывать почти весь свой код, либо Васе нужно придумывать костыли...
Если проект - одиночный небольшой сервис вокруг базы данных, то да, а если это проект в котором десяток различных составляющих, неочевидным для данного программиста образом взаимодействующих, он кукухой тронется, пытаясь поднять локально функционирующую копию всего сервиса в докере.
Иными словами, микросервисная архитектура хороша там, где у проекта много составляющих, которые делают разные люди. Каждый из них знает свою часть и может её прогнать на своём локальном компе в примитивной установке (банально curl'ом руками попинать), не пытаясь запустить весь комбайн.
Монолит практически невозможно распараллелить, то есть пилить его в два-три-четыре рыла в одном и том же куске проекта, монолит может пилить один, максимум два человека. Например, один фронтэндщик и один бэкендщик.
Тут не систему ломают, а внимательность проверяющих проверяют :)
Хотя, если в предоставленном скриншоте изменения очевидны (изменения в том что вроде бы не поменялось), то юникод в новых строках не так заметен, как в изменяемых.
один из участников проекта заменил символ ASCII на альтернативу Unicode в pull request, но никто в команде GitHub этого не заметил
А что, должны были? Команда гитхаба просматривает пулл реквесты чужих проектов?
Может, проблема лишь в отсутствии человекопонятного пояснения в интерфейсе, что строка имеет юникод, на которое должны обратить внимание мейнтейнеры при проверке пулл реквеста?
Ни слова о k8s, только докер упомянут. А между прочим, микросервисы без k8s теряют смысл.
И ещё плюс микросервисов, не упомянутый никак: в случае ошибки в коде монолита, можно получить нерабочий весь монолит (например, логинится юзер и видит белый лист из-за 500 ошибки в коде функции которая данные из таблички выгребает), в то время как в микросервисной архитектуре ляжет лишь конкретный микросервис (и условно вместо белого листа у юзера будет почти весь интерфейс и белый прямоугольник там где функция должна была вернуть данные для отрисовки графика)
Наконец, пример из жизни: ребята не могут вылить в деплоймент код api сервера, потому что в имеющейся админке монолита который api реализует есть уязвимые сторонние библиотеки, хотя они не используются в работе api и нужен секс по обновлению зависимостей для успокоения анализатора уязвимостей. В случае архитектуры микросервисов, api был бы независим от админки, что упростило бы выкладку.
Судя по отсутствию ссылок на первоисточник, текст сгенерирован не очень одаренным интеллектом, возможно искусственным
Вайбкодил я эти тесты. Такая херня получалась...
Да можно и на мыльницу снять, если выдержку достаточную поставить, и наловить фотонов во всё тот же пиксель матрицы. Даже если атом там не один, или его мотыляет полем туда-сюда) Картинка не изменится.
Я к тому, что полноценным фото атома можно считать такое, на котором понятно, что это действительно один атом. В данном случае пиксель фотоаппарата соответствует огромной области, наверное миллионов атомов, и что это фото одного, да ещё и конкретного, а не другого - можно только поверить на слово.
Формально, это не фото атома, а регистрация света, рассеянного на электронах одного атома.Было бы там не один атом а два, десять, тысяча - фото было бы точно таким же :)
Так ведь обычно на маршруте не один состав едет. Возврат энергии в сеть просто приводит к уменьшению потребления из сети другими составами. Чтобы "спалить ТП", нужно совпадение, когда (почти) все составы одновременно тормозят, и (почти) нет разгоняющихся. То есть, грубо говоря, суммарное потребление всех составов на линии вдруг оказывается ниже их суммарной генерации. С учётом, что рекуперация как правило даёт лишь около половины энергии, затраченной на разгон, вероятность этого не высока при более чем двух-трёх составах на одном участке тока.
Знаю что например в Германии перон поделён на секторы (A\B\C\...) длиной где-то 10-20 метров, и в билете указано, в каком секторе ваш вагон будет.
Две
Забыл вам про это ответить сразу, отвечаю отдельным постом.
Вы, вероятно, о ПЦР, изобретённой Кэрри Муллисом. Эта реакция позволила значительно увеличить скорость перевода генетической информации из физической структуры в AGTC последовательность, которую мы уже можем записать хоть на бумаге хоть в компьютерной программе. Однако, наличие AGTC последовательности не означает, что мы сразу её понимаем. Это как умение читать иероглифы - научиться отличать один от другого не проблема. Проблема в том, чтобы понимать смысл написанного ими. И ПЦР в общем-то не сильно нас продвинула в понимании ДНК кода. Он просто научил нас быстро его читать.
Все эти истории "получили системный промт" вызывают у меня один вопрос - а откуда уверенность, что это и есть "заложенный в систему разработчиками промт", а не выхлоп бредогенератора, который пытается соорудить юзеру что-то похожее на то, что он хочет?
Если задачу извлечения промта повторить несколько раз, с разных аккаунтов, с разной историей взаимодействия - насколько разными будут получены эти "системные промты"? Сколько процентов в них будет совпадать?
Откуда такая уверенность?
Какое это имеет отношение к симуляции?
По-моему, вы думаете что симуляция работы мозга компьютером примерно то же самое, что симуляция работы процессора другим процессором. Но это совсем другое!
При создании симулятора процессора процессором, мы просто переводим инструкции с одного языка на другой. Это примерно как переводить с английского на японский - несмотря на различный алфавит, это не сложно. Но при этом симуляция происходит не на уровне скажем транзисторов, а на уровне языка инструкций. Поэтому, например, инструкция А на реальном процессоре занимает 6 тактов, а инструкция Б 12 тактов, а в симулированном процессоре - обе по 8 тактов, если не предпринять специально задержек, которые замедлят симуляцию, но соблюдят задержки.
А теперь представьте себе, что нужно перевести с английского на язык жестов. Как? Просто программы уже мало - нужно видеокамеру для "ввода" жестов собеседника и как минимум экран показывающий видеоряд жестов ему в ответ, причём это, конечно же, не то же самое что настоящие жесты рук.
Точно так же обстоит дело с симуляцией мозга. Если вы симулируете нейроны как чёрный ящик внутри которого ничего не происходит в физическим смысле, лишь матричное перемножение с какими-то весами - вы не получите действительно аналогию работы настоящего мозга, это будет довольно примитивная имитация. И её примитивность не позволит вам ни исследовать мышление, ни разрабатывать лекарства от альцгеймера или шизофрении, ни изучать восстановление после инсульта - короче ничего реально полезного. Ничего из того, что было заявлено как цель проекта симуляции мозга.
А как достичь симуляции на уровне, который позволит этого? Что, симулировать настоящую химию всех этих нейромедиаторов, цикл Кребса, эмулировать взаимодействие молекул? А пупок не развяжется от моделирования взаимодействия 10 в 25 степени молекул?
Ню-ню. Учёные раньше тоже так думали. И даже пытались, и не раз.
https://en.wikipedia.org/wiki/Blue_Brain_Project
https://en.wikipedia.org/wiki/Human_Brain_Project
Таким образом, задача симуляции мозга на текущем нашем техническом уровне всё ещё невозможна.
Это было следствием невозможности быстро просчитать произвольные позиции
Через копилот
Ага, но вскоре начинаются проблемы совместимости разных третьесторонних модулей, потому что Вася использует приблуду завязанную через зависимости на некий плагин энной ветки, а Петя ветки эн плюс эм, и в зависимости от версии, впиленной в монолит, не работает либо Петин код, либо Васин :)
Или другой вариант - скажем, код Пети работает на nodejs v.18 и ниже, а код Васи не может работать ниже чем на nodejs v.20, и либо Пете надо переписывать почти весь свой код, либо Васе нужно придумывать костыли...
Если проект - одиночный небольшой сервис вокруг базы данных, то да, а если это проект в котором десяток различных составляющих, неочевидным для данного программиста образом взаимодействующих, он кукухой тронется, пытаясь поднять локально функционирующую копию всего сервиса в докере.
Иными словами, микросервисная архитектура хороша там, где у проекта много составляющих, которые делают разные люди. Каждый из них знает свою часть и может её прогнать на своём локальном компе в примитивной установке (банально curl'ом руками попинать), не пытаясь запустить весь комбайн.
Монолит практически невозможно распараллелить, то есть пилить его в два-три-четыре рыла в одном и том же куске проекта, монолит может пилить один, максимум два человека. Например, один фронтэндщик и один бэкендщик.
Тут не систему ломают, а внимательность проверяющих проверяют :)
Хотя, если в предоставленном скриншоте изменения очевидны (изменения в том что вроде бы не поменялось), то юникод в новых строках не так заметен, как в изменяемых.
А что, должны были? Команда гитхаба просматривает пулл реквесты чужих проектов?
Может, проблема лишь в отсутствии человекопонятного пояснения в интерфейсе, что строка имеет юникод, на которое должны обратить внимание мейнтейнеры при проверке пулл реквеста?
Ни слова о k8s, только докер упомянут. А между прочим, микросервисы без k8s теряют смысл.
И ещё плюс микросервисов, не упомянутый никак: в случае ошибки в коде монолита, можно получить нерабочий весь монолит (например, логинится юзер и видит белый лист из-за 500 ошибки в коде функции которая данные из таблички выгребает), в то время как в микросервисной архитектуре ляжет лишь конкретный микросервис (и условно вместо белого листа у юзера будет почти весь интерфейс и белый прямоугольник там где функция должна была вернуть данные для отрисовки графика)
Наконец, пример из жизни: ребята не могут вылить в деплоймент код api сервера, потому что в имеющейся админке монолита который api реализует есть уязвимые сторонние библиотеки, хотя они не используются в работе api и нужен секс по обновлению зависимостей для успокоения анализатора уязвимостей. В случае архитектуры микросервисов, api был бы независим от админки, что упростило бы выкладку.