Эта статья выросла из бесед с Godot-разработчиками. Они заботятся о том, чтобы поднимаемые проблемы решались, и стремятся улучшать ситуацию. Определённо, в Godot грядут серьёзные изменения, но сама платформа пока находится на ранней стадии развития. Поэтому сложно говорить с уверенностью, что именно изменится и в какой степени. На самом деле, я полагаю, что Godot ждёт самое светлое будущее.  

Апдейт: ведущий разработчик Godot Хуан Линьетски опубликовал ответ на этот пост.

Преуведомление

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

Выпуск Java 21 состоялся 19 сентября 2023 года. В этой версии поддерживаются паттерны записи в switch-блоках и выражениях. Такой синтаксис выглядит монументально (как минимум, по меркам Java). Это водораздел, после которого мы вправе говорить, что в Java полноценно поддерживаются паттерны функционального программирования, подобно тому, как это сделано в Kotlin, Rust или C#. Вот и первый пункт, который пробуждает во мне зависть (я Kotlin-разработчик).

Серверные компоненты React – это большой кусок работы. Недавно мы переосмыслили нашу документацию и устроили ребрендинг Mux. Пока мы этим занимались, мы перенесли весь материал сайтов mux.com и docs.mux.com на серверные компоненты. Так что, поверьте мне… я знаю. Знаю, что это возможно, не так страшно и, в принципе, что дело того стоит.

Давайте я вам объясню, почему, ответив на следующие вопросы: почему так важны серверные компоненты, а также для чего они хороши? Для чего они не так хороши? Как их использовать, как их постепенно внедрять и какие продвинутые паттерны следует использовать, чтобы всем этим управлять? Дочитав эту статью, вы станете замечательно представлять, следует ли вам использовать серверные компоненты React, а если следует – то как использовать их эффективно.

Сколько родилось отличных проектов open source, потому что у кого‑то руки чесались что‑то попробовать! Именно так было и в случае с Firecracker. В 2014 году компания Amazon запустила AWS Lambda, которую позиционировала как «бессерверную» вычислительную платформу. В AWS Lambda пользователь может задать функцию — скажем, десять строк кода на Python — а Lambda в ответ достроит всю требуемую инфраструктуру, чтобы сработала цепочка: прибывает HTTP‑запрос, вызывается функция, запрос обрабатывается, и, наконец, генерируется ответ.

Чтобы этот сервис работал безопасно и эффективно, Amazon нужно было разработать механизм, который позволял бы с минимальными издержками запускать виртуальные машины. Так появился Firecracker. Это монитор виртуальных машин (VMM), работающий совместно с Linux KVM. Он запросто создаёт «микро-VM» и управляет ими.

Некоторое время назад в Интернете ходила статья о неопределённом поведении, просто бесившая коренную аудиторию Rust. Завсегдатаи С и C++ в ответ только бурчали, что кто-то просто не понимает Всех Тонкостей и Нюансов Их Светлейшего Языка. Как обычно, пришло время и мне постараться изо всех сил и вставить мои пять копеек в эту застарелую дискуссию.

Готовьтесь поговорить об Основной Проблеме языков C и C++, а также о Принципе Лома.

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

Как подтвердит любой, кому когда-либо доводилось проходить собеседование по программированию, при наличии арифметической и геометрической прогрессии геометрическая всегда возобладает. При горизонтальном масштабировании расходы растут линейно (арифметически). Но по закону Мура вычислительные мощности со временем растут экспоненциально (геометрически). Это означает, что можно несколько лет ничего не делать, а затем масштабировать систему вертикально и получать улучшение на порядки. За двадцать лет плотность транзисторов возросла в  1000 раз. Это значит, что такая задача, для решения которой в 2002 году потребовались бы тысячи машин, сегодня выполнима всего на одной.

Вы когда-нибудь пробовали скачивать видео с YouTube? Я имею в виду ручками, а не через такие софтины, как youtube-dl, yt-dlp или один из «этих» сайтов. Оказывается, это гораздо сложнее, чем можно было бы подумать.

Youtube зарабатывает на показе рекламы пользователям. Поэтому с точки зрения платформы логично внедрить специальные ограничения, которые не позволяли бы скачивать видеоролики или даже просматривать их через неофициальный клиент, например, YouTube Vanced. В этой статье будут пояснены технические детали тех механизмов безопасности, что действуют в Youtube, и рассказано, как их обойти.

Привет, Хабр. Вашему вниманию предлагается сокращённый перевод эпичного поста под авторством Энди Уорфилда, вице-президента и заслуженного инженера в компании Amazon, занятого разработкой S3. Пост основан на его пленарном выступлении с конференции USENIX FAST ‘23 и затрагивает три различных аспекта, касающихся выстраивания и эксплуатации такого огромного хранилища данных как S3. Если пост окажется интересным - рассмотрим вариант перевести и вторую часть

От переводчика: выражаю огромную искреннюю благодарность Дмитрию Малову @malovdmitrijза консультации по ходу этого перевода, помощь в подборе формулировок, пояснение рисунков и незаменимую человеческую поддержку.

tldr; в статье рассмотрены приёмы, позволяющие ускорить обучение больших языковых моделей (LLM) и нарастить в них логический вывод. Для этого нужно использовать большое контекстное окно, в котором умещается до 100K входных токенов. Вот эти приёмы: ALiBi с подмешиванием в вектор позиции слова в последовательности (positional embedding), разреженное внимание (Sparse Attention), мгновенное внимание (Flash Attention),  многозапросное внимание, условные вычисления и GPU A100 на 80 ГБ.  

Как ушлый румынский экономист легально обставил лотерейную систему, выиграв миллионы долларов по всему миру.

Вечером в минувшую среду один калифорниец выиграл $1,08 миллиарда в лотерею Powerball – это один из самых больших кушей в истории. Но не эта игровая победа самая невероятная в истории. Ниже предлагается перевод сюжета, впервые опубликованного в августе 2018 года и рассказывающего об экономисте, по-настоящему преуспевшем в лотереях:

15 февраля 1992 года вскоре после 11 утра неказистый лототрон, крутившийся в эфире лотереи Штата Виргиния, выдал на всеобщее обозрение 6 шаров с выигрышными номерами: 8… 11… 13… 15… 19… 20.

В ближайшие дни властям довелось выяснить, что «некто» сорвал не только джекпот на сумму $27 036 142, но и 6 вторых призов, 132 третьих и 135k мелких выигрышей на сумму ещё $900k.

Когда этот казус удалось распутать, выяснился страннейший и самый невероятный эпизод в истории лотерей. Участниками сюжета стали тысячи инвесторов из разных стран мира, десятки сложных компьютерных компьютерных систем и савант-математик, подчинивший себе работу целой лотереи, сам будучи на другом конце света.

Это история о человеке, «обыгравшем» лотерею, просто выкупив в ней все до одной возможные комбинации.

Вот вам тупой вопрос, который вы сами, наверное, никогда себе не задавали. Каково минимальное количество байт, которые необходимо сохранить в исполняемом .NET-файле, чтобы CLR напечатала "Hello, World!" в консоли стандартного вывода?

Да, такого я не ожидал. Записал пару неказистых видосов за пять минут, опубликовал в треде Twitter, а они завирусились, набрав к моменту подготовки статьи 8,8K лайков. В самом деле не мог такого спрогнозировать, учитывая, что я годами вывешиваю только такой контент, который интересен лично мне… и ничего, отклик почти нулевой. Теперь, когда ситуация поостыла, время навести суету и с известной тщательностью изложить возникшие у меня мысли.

На дворе 2023 год. Весь Интернет — под контролем Империи GAFAM. Весь? Нет, несколько мелких анклавов пока не поддались их гнёту. А некоторые из этих непримкнувших стали объединять усилия, консолидируясь в «Федиверс».

В ходе дебатов на просторах Twitter и Reddit, Федиверс стал привлекать всё больше внимания и снискал славу. Люди стали всерьёз им пользоваться. Это не могло укрыться от внимания Империи.  

Распространено мнение, будто современные высокопроизводительные процессоры x86 работают так: декодируют «сложные» инструкции x86 в «простые» RISC-подобные инструкции, которые затем обрабатываются в оставшейся части конвейера. Но насколько эта идея на самом деле отражает, как именно устроен внутри процессор?

Чтобы ответить на этот вопрос, давайте проанализируем, как следующий простой цикл обрабатывают различные процессоры x86, от P6 (первой микроархитектуры Intel «современного» типа до современных конфигураций). Код сделан 32-разрядным лишь для того, чтобы можно было затронуть и очень старые процессоры с архитектурой x86.

С прошлой осени Нивен проходит стажировку, разрабатывая новую модель псевдонимов для Rust: древовидные заимствования (tree borrows). Секундочку, уже слышу, как вы вопрошаете: а разве в Rust ещё нет своей псевдонимной модели? Разве вы, автор, не рассказываете повсюду о «стековых заимствованиях»? Действительно, так и есть, но стековые заимствования — всего лишь один из возможных вариантов реализации для модели псевдонимов, и с этим вариантом есть свои проблемы. Древовидные заимствования призваны учесть опыт, усвоенный при работе со стековыми заимствованиями, и построить новую модель, не такую проблемную. Также при её проектировании принимаются немного иные решения, с учётом некоторых нужных компромиссов и той тонкой настройки, которая, возможно, должна быть привнесена в эти модели, и только потом настанет время решать, какую же из этих моделей принять в Rust в качестве официальной.

У себя в блоге Нивен написал подробное введение в древовидные заимствования, и не помешает сначала прочитать этот ознакомительный материал. На прошедшей недавно конференции RFMIG он выступил с лекцией на эту тему, и его доклад вы также можете посмотреть, вот здесь. В этом посте я сосредоточусь на том, чем древовидные заимствования отличаются от стековых. Предполагаю, что вы уже ориентируетесь в стековых заимствованиях и хотите понять, что меняется с введением древовидных заимствований.

Для краткости я буду иногда называть стековые заимствования «СЗ», а древовидные заимствования — «ДЗ».

В одном недавнем подкасте о том, кто сейчас главный в Rust, вновь всплыл вопрос о том, кому быть BDFL (великодушным пожизненным диктатором), и Джереми Соллер сказал (это был чемпионский заход на приз «за преуменьшение века»): «Я считаю, Грейдон забраковал бы некоторые вещи, которые всем нам сейчас нравятся». Этим он вторит другой дискуссии на reddit, в которой мне напомнили, что я собирался как-нибудь расписать, каким образом «я сделал бы всё по-другому». Вероятно, это бы крайне не понравилось всем причастным, и эти идеи далеко бы не распространились.

Ну и ну. Я понял, что следующий момент не вполне очевиден и он, пожалуй, заостряет вопрос, «а действительно ли в проекте нужен BDFL». Так вот, озвучу его: Rust Нашего Времени далеко, далеко отстоит от Rust Моей Мечты. Главное, не поймите меня неправильно: мне нравится, что у нас получилось. Получилось отлично. Я воодушевлён, что теперь есть столь жизнеспособная альтернатива C++, в особенности такая, которую другие люди уже начинают воспринимать как норму, как реальный вариант для повседневной работы. Я пользуюсь Rust и очень доволен, что могу отдавать ему предпочтение перед C++. Но!

Я столько всего сделал бы в Rust по-другому, если бы всё это время «отвечал» за его развитие.

Вам знакомы муки, когда пытаешься добиться чего-то от тормознутого сайта, а он не реагирует на щелки мыши или пробуксовывает при прокрутке? Подобные проблемы с производительностью могут провоцировать:

Нервозное перещёлкивание (rage clicking)

Повышенный отток пользователей и снижение показателей конверсии

Потерю позиций в поисковой выдаче

Более трёх лет мобильная версия Википедии сбоила из-за фрагмента кода на JavaScript, выполнение которого могло занимать более 600 мс при загрузке страницы на маломощных устройствах. В результате работать со страницей становилось попросту невозможно.

Я начал программировать Rust несколько лет назад, и эта работа постепенно позволила мне изменить подход к проектированию программ и на других языках. В особенности заметен этот эффект был на Python. Прежде, чем я приступил к использованию Rust, я обычно писал код Python в очень динамичном стиле со свободной типизацией, без подсказок типов. Я повсюду передавал и возвращал словари, от случая к случаю прибегая к интерфейсам со «строковой типизацией». Правда, ощутив на себе всю строгость системы типов Rust и познакомившись со всеми теми проблемами, которые Rust решает «по природе», я вдруг сильно разволновался, когда пришлось вернуться к Python, и оказалось, что там и близко нет таких гарантий, как в Rust.

В 2015 году я написал статью о том, как было улучшено квантование цветовой палитры в FFmpeg для создания красивых анимированных гифок. По какой-то причине эта статья — по сей день самая популярная из всех моих постов.

Время шло, я набирал опыт в работе с цветами и в результате стал весьма стыдиться и переживать по поводу того, в каком состоянии лежат мои фильтры. Многий код в них был наивен (а то и ужасно неправилен), несмотря на всю очевидную результативность этих фильтров.

Вот в чём заключалось одно крупное изменение, которое я хотел внести: оценить расстояния между цветами, воспользовавшись при этом равномерно воспринимаемым цветовым пространством, а не наивное евклидово расстояние между RGB-тройками. 

Как обычно, казалось, что с таким проектом можно управиться за неделю. В конце концов, мне всего-то и требовалось изменить функцию расстояния, так, чтобы она стала работать в ином пространстве, верно? Что ж, как обычно, я сам себе устроил множество приключений, наслоившихся друг на друга:

В прошлом году Дэниэл Стенберг, создатель curl, написал пост об одном забавном URL:

http://http://http://@http://http://?http://#http://

Пост интересен, рекомендую его прочитать. Автор объясняет, как устроен URL, и как различные системы его обрабатывают.

Но в том посте не разобрано, в частности, как сказывается такая разница в обработке одних и тех же URL различными системами. В этой лекции 2017 года (слайды, видео) Оранж Цай рассматривает и многие другие несогласованности между различными библиотеками, а также риски из области безопасности, возникающие из-за такой несогласованности.

В лекции данная тема раскрыта в мельчайших (и очень увлекательных) деталях, но здесь я хотел бы резюмировать суть.