Веб-версияОткрыть в Telegram
FFAANG Master

FAANG Master

@faangmaster · канал · Технологии · в индексе с 2026-05-29
2 940подписчиков−13 за неделю
3 339средний охват поста
1постов за 30 дней
777постов в индексе
F
FAANG Master
Exit стратегия ранних инвесторов в Open AI, Anthropic и Space X заключается в использовании пенсионных накоплений американцев Такая дискуссия разворачивается в преддверии самых масштабных IPO в истории. В этом году на IPO выходят SpaceX, OpenAI и Anthropic. Ранние инвесторы вкладывали колоссальные деньги в эти компании по астрономическим оценкам. Все три компании глубоко убыточные. Revenue (доход) измеряется десятками миллиардов долларов в год. При этом оценка капитализации в триллионах долларов. Выход на IPO — это один из вариантов вернуть инвестиции и заработать на них. Но что необычного сейчас происходит? Крупные индексы, вроде Nasdaq, Russell 1000, S&P 500, изменили правила включения компаний специально под эти 3 компании. Они сократили время включения до недель и даже дней, вместо месяцев или даже года. Кроме того, S&P 500 исключил правило, что для включения компании в индекс нужно, чтобы компания была прибыльной. То есть, Индексы планируют включить эти компании в портфели почти по стартовой цене, без ожидания установления рыночной цены. Но как это связано с пенсиями в США? В США существенная часть пенсий поступает от так называемых инвестиционных счетов 401(k). Работник может откладывать часть своего дохода на специальный инвестиционный счёт. Например, 5%. Часто работодатель может добавить столько же. То есть вы можете откладывать 10% своего дохода на инвестиционный счёт. Причём вы откладываете процент дохода до уплаты налогов. То есть то, что вы туда откладываете, идёт в обход уплаты налогов. И когда вы перечисляете туда деньги, вы можете выбрать индексы, в которые вы инвестируете. Снять деньги со счёта до достижения пенсионного возраста очень сложно, и придётся платить штраф за это. Теперь получается так, что эти компании насильно и по практически изначальной цене включают в индексы, и следовательно, это частично оплачивается из пенсионных накоплений американцев. Соответственно, ранние инвесторы могут быстро продать свою долю и выйти по астрономиче
28 · 1.8K ·
FAANG Master
Почему самые высоконагруженные веб приложения мира это не всегда микросервисы? Многие компании, которые разрабатывают самые высоконагруженные приложения, с миллиардами запросов в секунду, используют монолиты и монорепы. Ярким примером является Facebook и Instagram. В бэкенде это монолиты. Конечно, у них есть большое число других компонент, которые вынесены в отдельные сервисы, но основной backend, который принимает и обрабатывает запросы от фронтенда (веба или мобильного приложения), содержит бизнес логику - это монолит. Backend Facebook изначально был написан на PHP в 2004 году. Далее его плавно мигрировали на собственный язык hacklang и собственную виртуальную машину hhvm. При этом он остался, по большей части, колоссального размера монолитом. Аналогично, Instagram написан на python (django). Основная часть все еще остается монолитом. Оба сервиса имеют миллиарды пользователей и обрабатывают невероятное число запросов в секунду. При этом они обладают колоссальной отказоустойчивостью и скорость разработки сервисов огромная. Время от того, как вы запушили комит до деплоя в prod проходит несколько часов. Более того, весь код этих приложений находится в монорепе и используется trunk-based development. Т.е. все изменения сразу делаются в основной ветке разработки. Почему так? Какие это дает преимущества? Монорепа: 1) Проблема версионирования API решается на уровне компилятора. Если вы меняете какое-то API, то вы не сможете запушить это изменение в trunk до тех пор, пока не измените все call site (все места, где это API вызывается). Вам не позволит компилятор, ваш код просто не скомпилируется. Если у вас множество репозиториев, то изменение API в одном месте не блокирует вас запушить это изменение. Вы создадите новую версию вашего API. Всем клиентам нужно про это узнать, и делать процесс миграции на новую версию. Нужно менять код, зависимости и т.д. Очень часто это приводит к багам в проде. Когда клиент ожидает одного поведения или семантики API, а в проде уже з
25 · 1.8K ·
Какие есть с этим проблемы и как их решили в Facebook/Instagram? 1) Производительность системы контроля версий. Если у вас очень много кода в одном репозитории как в Meta (миллионы файлов, десятки, если не сотни миллионов строк), то система контроля версий может на справиться по производительности. Поэтому Мета сделала свою систему контроля версий на основе Mercurial (git не справлялся с такими масштабами). 2) Feature Flags. Из-за trunk-based development у вас деплоится множество функционала в промежуточном состоянии. Для этого вам нужно иметь возможность ее включать и выключать в проде, проводить тестирование в проде и т.д. Для этого вам нужно активно использовать feature flags. 3) Привязка к одному языку программирования. Это неустранимая особенность. Приходится писать на том языке, на котором написан монолит. 4) Влияние проблем в одной фиче на другую/независимое масштабирование. Если одна функциональность стала работать плохо (потреблять много памяти, бросать ошибки, потреблять много процессорного времени и т.д.), то это может повлиять на работоспособность другого функционала, т.к. весь функционал живет на одном и том же сервере (т.к. это монолит). Это решено на уровне виртуальной машины/контейнера приложений. В Python у вас создается несколько отдельных процессов. Которые способны обрабатывать запросы независимо друг от друга. Число процессов зависит от числа ядер процессора. Процессы не шарят между собой память. Их можно независимо друг от друга мониторить, убивать и перезапускать. В hacklang и hhvm процесс один, но имеет множество потоков, которые имеют изолированную память, которую можно независимо друг от друга ограничивать. Потоки более легковесные, чем отдельные процессы. Но при этом они не шарят память между собой. В Java такое реализовать не получится. Там также один процесс и отдельные потоки на каждый запрос. Но потоки используют одну и туже память (Java Heap). 5) Проблемы с ownership кода. Из-за того, что весь код в одной большой куче, сложно разгра
15 · 2.4K ·
F
Фотография
нажмите — покажем
Starbucks отказался от AI системы для инвентаризации В сентябре 2025 года новый CEO компании Брайан Никкол решил побороть вечную проблему нехватки ингредиентов в кофейнях. В 11 тысячах точек США и Канады внедрили систему Automated Counting (от разработчика NomadGo). Бариста должны были просто навести планшет с камерой на полки с сиропами, молоком и кофе, а нейросеть с помощью компьютерного зрения должна была сама всё посчитать и заказать то, что заканчивается. На практике: Нейросеть регулярно путала разные виды молока (например, обычное с миндальным или соевым). ​Система не видела некоторые позиции или, наоборот, считала один пакет за два. ​Из-за постоянных галлюцинаций ИИ бариста приходилось тратить массу времени на ручную перепроверку данных, что полностью убивало смысл автоматизации. После 9 месяцев мучений, в итоге, они отказались от системы и перешли на ручной учет. При этом, они недавно ввели KPI для своих корпоративных сотрудников по использованию AI (токенмаксинг) и привязали это к премиям и т.д.
19 · 3.5K ·
FAANG Master
Heatwave в Лондоне На этой неделе в Лондоне ожидается сильная жара. До +38°C. Обычно, такую погоду в UK называют heatwave (хитвейв). При этом жара в UK переносится сильно хуже, чем в других странах. Тут даже температура выше +25°C уже не сильно комфортная. Это связано с несколькими факторами: 1) Отсутствие кондиционеров в домах. Тут практически не бывает кондиционеров в жилых домах. Кондиционеры есть, в основном, только в офисах и магазинах. Сверлить фасад здания и повесить кондиционер вам никто не даст. 2) Дома - термосы. Дома строились с расчетом на накопление и удержание тепла внутри. У них хорошая теплоизоляция. А также стены сделаны из материала, который хорошо нагревается и долго держит тепло. Это хорошо в прохладную погоду, но не летом. Тут, в отличие от Германии и других стран Европы, не холодно зимой в домах. В Дюссельдорфе и Люксембурге, где я жил до Лондона, было сложно получить температуру выше 19-20 градусов зимой без больших счетов на коммуналку. В Лондоне такой проблемы нет (ну или не так заметна). Но летом это превращается в ад. Дом нагревается в жару и даже после того как жара спадает, стены продолжают еще долго отдавать тепло внутрь и удерживать от потерь наружу. На улице уже может быть 20, а в доме все еще больше 25. 3) Нет внешних ставень. Во многих странах Европы на окнах есть внешние ставни. Закрывать их можно изнутри дома. При этом они полностью блокируют свет, благодаря чему не нагревается само окно и помещение внутри. В Лондоне такого нет. Более того, во многих квартирах окна от потолка до пола, т.е. у вас такой аквариум, который сильно прогревается солнцем со всех сторон. В Люксембурге у меня в квартире были ставни, хотя страна не южная, типа Испании. Это было особенно хорошо ночью, можно было создать полную темноту в помещении на ночь. И все это хорошо сочеталось с +19°C внутри. Спать было заметачельно. 4) В жару очень часто полностью чистое небо. Не смотря на репутацию туманного Альбиона и дождливой страны, тут бывает очень солнечно.
16 · 2.1K ·
F
Основные причины багов в проде Это мой личный рейтинг причин на основе работы в 5 компаниях в 4 странах в течении почти двух десятков лет: 1) Качество разработчиков. В начале карьеры я думал, что основная причина - отсутствие процессов. Но потом на практике убедился, что это не так. Какие бы не были процессы (код ревью, тестирование, мониторинг и т.д.) вы не сможете всего предугадать и сделать защиту от дурака от всех возможных случаев. Процессы помогают, но при низком качестве разработчиков это не спасет от всех возможных случаев. В Мета процессов почти нет, тестирование минимально, при этом количество багов не такое большое. Если вы будете нанимать верхние персентили разработчиков по качеству (что бы это не значило), то они будут сразу писать правильно и без багов. 2) Конфигурации. Это вообще топ причина для фангов. Что в Амазоне, что в Facebook/Meta sev0, Large Scale Event аутеджи чаще всего случаются из-за деплоя конфигураций в прод. Конфигурации практически никак не тестируются, быстро деплоятся в прод (минуты). И никто не знает как они повлияют на систему. В них нет/мало проверок, как автоматических так и ручных. Нет особых процессов. Нет интуиции и опыта, как с кодом. Поэтому качество программистов не всегда спасает. 3) Проблемы версионирования/API. Это актуально, если у вас не монолит. Если вы дергаете какую-то зависимость, но ее поведение изменилось и стало не таким каким вы его ожидаете или изменился протокол взаимодействия, то это приводит очень часто к багам. Это типичная проблема микросервисных архитектур, особенно, когда зависимостей очень много. 4) Miscommunication, неправильное понимание задачи/бизнес логики. Тут часто не спасают ни тесты, ни качество программистов. Тесты не спасают, т.к. если вы не правильно поняли как это должно работать, то и в тесте вы будете проверять, что оно работает как ожидаете вы, а не как правильно. Качество программиста тут только гарантирует, что оно будет работать как вы ожидаете, но не как правильно. 5) Проблемы зав
31 · 1.8K ·
F
FAANG Master
Топ городов Европы для миграции программиста в 2026. Долгосрочная миграция с возможностью работы в BigTech/FAANG Включил 18 городов Европы и Дубай. США, Южную и Центральные Америки, Азию, Австралию не рассматривал. Сделаю несколько топов из этих городов, т.к. разные города хороши под разные типы и цели миграции. Сегодняшний топ фокусируется на долгосрочной миграции, с целью получения гражданства, покупки недвиги, долгосрочной жизни и работы в разных компаниях, которые нанимают в этом городе. Не для тех кому нужно срочно уехать куда-то. Не для тех, кто хочет жить у моря, не важно где, работая на удаленке. А также рассматривает возможность поработать в FAANG/BigTech-компаниях в этом городе. Не для тех, кто хочет выйти на пенсию, живя на инвестиции (FIRE). Я проанализировал 13 различных параметров (получение гражданства, зп, стоимость жизни, стоимость недвиги по отношению к зп, климат, преступность, медицину, образование, наличие FAANG, удобство жизни зная только английский и т.д.), составил скоринг метрику и вот что у меня получилось: 1) Лондон. Был сам удивлен. 38 баллов. Хорош в: получении гражданства, не нужно отказываться от первого гражданства. Много вакансий, много FAANG/BigTech. Английский. Топ университеты. Средний/ниже среднего в: стоимости жизни, преступности, стоимость покупки недвижимости. 2) Цюрих. 34 балла. Хорош в: безопасность, образование, FAANG/BigTech компании, распространенность английского, высокие зп по отношению к стоимости жизни и стоимости недвиги. Плох в: получении гражданства, мало вакансий, кроме FAANG. 3) Берлин. 32.5 балла. Хорош в: получении гражданства. В остальном нет откровенно плохих метрик, по всем средний/выше среднего. 4) Дубай. 32.3 балла. Хорош в: стоимость жизни по отношению к зп, налоги, стоимость недвиги по отношению к зп. Плох в: нельзя получить гражданство, климат, нет фангов. 5) Амстердам. 31.7 балла. Во всем чуть выше среднего. Ниже среднего: не много вакансий, стоимость жизни и недвиги по отношению к зп. 6) Варшава.
57 · 2K ·
FAANG Master
В продолжении рейтинга городов Европы. Рейтинг по покупке недвижимости. Для тех, кому важна только возможность купить недвижимость. Для каждого города я вычислил медианную зп синьера в месяц после уплаты налогов. И месячный платеж по ипотеке за сферическую недвигу в вакууме (75 кв. метров) при 20% первоначальном взносе и 25 годах выплат. 1) Дубай. 15%. 2) Валенсия. 22%. 3) Кипр (Лимассол). 25% 4) Мадрид. 33% 5) Барселона. 36% 6) Брюссель. 36% 7) Цюрих. 38% 8) Порту. 42% 9) Варшава. 42% 10) Амстердам. 47% 11) Берлин. 47%. 12) Лондон. 47% 13) Стокгольм. 54% 14) Лиссабон. 56% 15) Прага. 58% 16) Франкфурт. 59% 17) Мюнхен. 69%. 18) Париж. 72% 19) Люксембург. 76%. Это при условии, что вы и работать будете в том же городе (а не удаленка на компанию из другой страны). Также часто есть обходные пути. Например, кажется, что в Люксембурге невозможно купить недвигу. Но многие покупают не в самом городе, а в соседних городах. Там всю страну за 2 часа можно объехать. Также есть возможность купить недвигу в несколько раз дешевше по специальным программам. Если это ваша первая недвига, вы ее не можете никому сдавать, а только в ней жить и продать вы ее можете только по цене покупки изначальному продавцу (лэндлорду). Знаю людей кто купил на условные 300-400 тысяч евро дом на 200 квадратов в 40 минутах от Люксембурга.
24 · 2.2K ·
F
Рейтинг городов Европы для Digital Nomad Это для тех, что зарабатывает, работая на полной удаленке и имеет возможность работать откуда угодно. Из 19 городов, я исключил те, где нет никакой возможности получить визу, если вы не работаете в этой стране. При расчете рейтинга я учитывал: стоимость жизни, стоимость недвиги, легкость получения Digital Nomad Visa, климат, медицину, преступность, язык. Итоговый рейтинг: 1) Валенсия. 32 балла. Дешево, дешевая недвига, легко получить Digital Nomad Visa, море, солнце, хорошая медицина, низкая преступность. 2) Порту. 30 баллов. Аналогично Валенсии. Но нет моря (есть океан), чуть дороже недвига. 3) Кипр (Лимассол). 28 баллов. Подороже, чем Валенсия. 4) Лиссабон. 28 баллов. Дороже чем Валенсия, особенно недвига. 5) Барселона. 28 баллов. Дороже Валенсии, выше преступность. 6) Мадрид. 27 баллов. Как Барселона, но лучше с преступностью и нет моря. 7) Прага. 26 баллов. Сложнее получить такую визу. Нужно ИП открывать в Чехии. Дорогая недвига. 8) Франкфурт. 26 баллов. Сложнее получить такую визу. Дорогой город. Нет моря. 9) Мюнхен. 26 баллов. Аналогично Франкфурту. 10) Берлин. 25 баллов. Аналогично Франкфурту, но чуть дешевле. Также выше преступность, хуже медицина. 11) Варшава. 25 баллов. Нет моря, сложнее получить такую визу, дорогая недвига. 12) Дубай. 25 баллов. Жарко, дорого. 13) Париж. 24 балла. Сложно получить такую визу. Очень дорого. Нет моря.
36 · 2.5K ·
FAANG Master
Фотография
нажмите — покажем
Hope Driven Development становится все актуальней и актуальней с появлением AI.
17 · 2.7K ·
Фотография
нажмите — покажем
Фотография
нажмите — покажем
Фотография
нажмите — покажем
Еще несколько рекомендаций по литературе
12 · 3.8K ·
F
Фотография
нажмите — покажем
Ford наняла обратно уволенных инженеров по качеству Ранее Ford внедрила систему, основанную на AI, для контроля качества производства. Благодаря, чему уволила сотни инженеров. Внедрение AI системы привело к росту количества брака и отозванных автомобилей. Сейчас Ford наняла обратно 300+ опытных инженеров по качеству работать совместно с этой AI системой.
65 · 3.6K ·
F
FAANG Master
Ссылка
нажмите — покажем
Документалка про Java В продолжение темы документалок, вышла документалка про Java. Трейлер: Official Trailer Анонс: Java: The Documentary is Coming Soon Документалка: The Java Story
32 · 2.8K ·
F
FAANG Master
Фотография
нажмите — покажем
Фотография
нажмите — покажем
Фотография
нажмите — покажем
В свое время я закончил МФТИ. Относительно непростой вуз для обучения. Закончил неплохо. За время обучения выработал подход к подготовке к экзаменам, который часто применял после окончания вуза. Например, когда решил стать программистом или когда решил заботать алгосы, чтобы поработать в фангах. Подход следующий. Обычно, на подготовку к экзамену выделялось 4 дня. Для теоретических экзаменов давали список вопросов (билеты). Обычно, это 30-80 тем. Я старался разделить этот список на 3 части и ботать в день эту одну треть. Например, если 30 вопросов, то в день ботал 10 вопросов. Ботал примерно 12-14 часов в день. Каждый день был устроен примерно так. Читаю/изучаю какой-то вопрос по лекциям, книгам и т.д. Стараюсь разобраться пока не понимаю все детали. Далее воспроизвожу этот вопрос на бумаге с формулами и проговариваю про себя ответ на вопрос. И так по всем вопросам, которые я запланировал на день. В конце дня повторял все изученные вопросы за день. Иногда мы проговаривали эти темы вместе с соседями по общаге. Также спрашивали друг друга непонятные вещи, с которыми не смогли разобраться сами. На 4 день, я снова повторял все изученные билеты и доучивал все, что не успел за предыдущие три дня. Часто недоучивал несколько последних билетов, т.к. не хватало времени и/или капасити памяти/мозга. На них я писал бомбы и брал с собой. За все время они мне пригодились 1 раз. Выпал билет, который я не учил и я воспользовался бомбой. К письменным экзаменам подход похожий. Только вместо билетов, там типы задач. Подготовка была чуть проще, т.к. в течении семестра мы сдавали задания, где прорешивали десятки типовых задач. К письменному экзамену я находил варианты прошлых лет, которые были во внутренней сетке, и прорешивал с десяток другой задач на каждую тему (по матану, дифурам, общефизу и т.д.). Аналогичный подход я применял, когда решил изучить алгосы 11 лет назад. Я никогда не участвовал в олимпиадах по программированию и изучал все буквально с нуля. Основа подготовки: выясне
50 · 2.9K ·
F
FAANG Master
IOI 2026 В Ташкенте прошел межнар школьников по информатике. Результаты: https://stats.ioinformatics.org/results/2026 Официальный медальный зачет по странам не составляется. Также участники из некоторых стран не выступали под флагами своих стран (Россия, Белоруссия, Израиль и т.д.). Разбивка по странам: https://stats.ioinformatics.org/contestants/2026 В конце там есть участники из этих стран. Владислав Жиганов из России занял абсолютное второе место: https://stats.ioinformatics.org/people/8665 Попросил нейронку сделать неофициальный зачет по медалям как на олимпийских играх и при равном числе медалей по сумме набранных баллов. Получившаяся первая 20ка: 1) Китай, 3-1-0, 1736.83 2) Израиль*, 3-0-1, 1499.01 3) Малайзия, 2-2-0, 1513.21 4) Россия*, 2-2-0, 1513.20 5) США, 2-2-0, 1487.67 6) Япония, 2-1-1, 1517.09 7) Корея, 2-1-1, 1353.45 8) Гонконг, 2-1-0, 1317.18 9) Польша, 2-1-0, 1312.10 10) Казахстан, 1-3-0, 1456.58 11) Турция, 1-2-1, 1350.16 12) Австралия, 1-2-0, 1314.80 13) Тайвань, 1-2-0, 1299.82 14) Украина, 1-2-0, 1286.81 15) Вьетнам, 1-2-0, 1244.42 16) Бразилия, 1-1-2, 1273.75 17) Румыния, 1-1-2, 1269.04 18) Беларусь*, 1-1-2, 1248.34 19) Болгария, 1-1-2, 1215.40 20) Филиппины, 1-0-2, 944.13 * — выступали без национального флага Составы сборных США: https://stats.ioinformatics.org/delegations/USA/2026 И Великобритании: https://stats.ioinformatics.org/delegations/GBR/2026
8 · 2.5K ·
F
FAANG Master
Новый HTTP метод QUERY Этим летом в спецификацию HTTP добавили новый метод - QUERY. Добавление новых методов происходит довольно редко. Последний раз такое добавление случалось в 2010 году, т.е. 16 лет назад. Тогда добавили метод PATCH. Какие причины добавления? Поиск с фильтрами/параметрами. По идее, можно для поиска использовать GET, т.к. он кэшируется и safe (read-only). Но передавать параметры через URI не удобно: есть лимиты, передавать сложные структуры через URI неудобно, URI также часто логируется, используется в качестве закладок в браузере. Поэтому на практике используют POST, который изначально под это не приспособлен. Параметры/фильтры передают через тело запроса. CDN, reverse proxy обычно не кэшируют такие запросы и перенаправляют на бэкенд, т.к. кэшировать по URI смысла нет без фильтров, которые в теле запроса. Более того, POST изначально предназначался для получения данных для возможного последующего сохранения, а не для read-only чтений, по типу поиска. Т.е. он не safe, а также не идемпотентен. Поэтому предложили новый метод - QUERY. Одна из компаний, которая его предложила - Cloudflare. Т.к. они делают, в том числе и, CDN. QUERY - safe и idempotent как и GET. Т.е. не меняет состояние сервера, read-only. Ответ кэшируется, но в ключ кэша обязано входить тело запроса и его метаданные. Он также возвращает Location, по которому можно при помощи GET получать те же данные, без пересылки тела запроса с параметрами. RFC: https://www.rfc-editor.org/info/rfc10008/
49 · 3.2K ·
F
FAANG Master
Фотография
нажмите — покажем
Фотография
нажмите — покажем
Uber совместно с британским стартапом Wayve запускает роботакси в Лондоне Пришла нотификация в приложении убера. Пока в режиме тестирования. Водитель все равно будет присутствовать на всякий случай. Все это будет на Ford Mustang Mach-E.
14 · 3.1K ·
F
FAANG Master
Навье-Стоксгейт 8 сентября OpenAI заявила, что её невыпущенная модель решила одну из семи "задач тысячелетия" - проблему существования и гладкости решений уравнений Навье–Стокса. Напомню, что до этого была решена лишь одна задача тысячелетия - Гипотеза Пуанкаре, которую доказал Григорий Перельман. Вначале ~100 агентов 50 часов решали упрощенную задачу о регулярности уравнений Эйлера. Далее результат скормили для решения задачи про уравнение Навье-Стокса. В пике работали около 10000 агентов в течении 88 часов. Потом еще 17 часов на проверку доказательства в Lean. Было потрачено токенов на более чем $22 млн. Доказательство уже выложено. Но пока независимой проверки не прошло. Все бы хорошо, но Open AI подозревают в плагиате и краже ключевой идеи доказательства. За 12 часов до анонса от Open AI математик Тристан Бакмастер опубликовал заявление, где анонсировал несколько прорывов в решении задачи Навье-Стокса. В частности для упрощенной задачи - уравнения Эйлера. И что по самой задаче Навье-Стокса они уже нашли доказательство, но оно пока еще не прошло Lean и статья еще не готова для публикации. Там же он рассказал, что они работали год над этим решением совместно с математиком, который работает в Антропик - Левентом Альпёге. И результатов по Эйлеру достигли 15 августа. Кроме того, в том же заявлении, он написал, что 3 сентября рассказал, про свой проект одному из сотрудников Open AI, после того, как поползли слухи, что в Антропик решили задачу тысячелетия. Тристан, сказал, что это с Левентом их личный проект и к Антропику отношения не имеет. Что Левент делает это не как сотрудник Антропика. После этого, через 3 дня Open AI делает свое доказательство использую абсолютно тот же подход, предложенный Бакмастером и Альпеге. 6 сентября Себастьен Бюбек из Open AI связывается с Бакмастером. По его словам, он хотел, чтобы все лавры доказательства достались Бакмастеру и Альпеге. Но в ходе разговора узнает, что Бакместер и Альпеге решили только Эйлера, но не Навье-Ст
27 · 3.3K ·

Открытая публичная лента из поискового индекса ChatCrawler — «Google по публичному Telegram»; обновляется по мере обхода площадки. Время — UTC.

Только публичный контент, официальный API Telegram. О проекте · Вопросы · Чего мы не делаем · Убрать страницу из выдачи · Каталог · Поиск · Как мы считаем