Когда приходишь просить повышения зарплаты у начальства

https://cs.android.com/android/platform/superproject/main/+/main:prebuilts/rust/bootstrap/README.md

TL;DR - в Google работают параноики (в хорошем смысле), их настолько беспокоит тема #bootstrap, supply chain attack, и атака Томпсона, что они, перед тем, как использовать rust в android, запилили его full source bootstrap.

Очень круто!

(спасибо подписчикам за ссылку)

Уборщик из Индии в Санкт-Петербурге оказался бывшим разработчиком по искусственному интеллекту. Он говорит, что работал в компаниях вроде Microsoft и использовал новые инструменты — ИИ, чат-боты, GPT и тому подобное.

В России у него другие задачи. Он с коллегами работает в Санкт-Петербурге Приморском районе и носят специальную нашивку в виде флагов Индии и России на форме. Для них организовано проживание и еда за счёт работодателя, а зарплата доходит до 100 тысяч рублей в месяц.

При этом у них есть профессии — среди прибывших бывший айтишник, предприниматель, организаторы свадеб, фермеры, водители, архитекторы, скульптор, кожевник. @banksta

https://xn--r1a.website/WhatDontYouLoveUsAnymore/18575

Осуждаю насилие, но затерпеть придётся

Тут Spotify забекапили

We backed up Spotify (metadata and music files). It’s distributed in bulk torrents (~300TB), grouped by popularity.

This release includes the largest publicly available music metadata database with 256 million tracks and 186 million unique ISRCs.

It’s the world’s first “preservation archive” for music which is fully open (meaning it can easily be mirrored by anyone with enough disk space), with 86 million music files, representing around 99.6% of listens.
. . .
Before we dive into the details of this collection, here is a quick overview:

- Spotify has around 256 million tracks. This collection contains metadata for an estimated 99.9% of tracks.
- We archived around 86 million music files, representing around 99.6% of listens. It’s a little under 300TB in total size.
- We primarily used Spotify’s “popularity” metric to prioritize tracks. View the top 10,000 most popular songs in this HTML file (13.8MB gzipped).
- For popularity>0, we got close to all tracks on the platform. The quality is the original OGG Vorbis at 160kbit/s. Metadata was added without reencoding the audio (and an archive of diff files is available to reconstruct the original files from Spotify, as well as a metadata file with original hashes and checksums).
- For popularity=0, we got files representing about half the number of listens (either original or a copy with the same ISRC). The audio is reencoded to OGG Opus at 75kbit/s — sounding the same to most people, but noticeable to an expert.
- The cutoff is 2025-07, anything released after that date may not be present (though in some cases it is).
- This is by far the largest music metadata database that is publicly available. For comparison, we have 256 million tracks, while others have 50-150 million. Our data is well-annotated: MusicBrainz has 5 million unique ISRCs, while our database has 186 million.
- This is the world’s first “preservation archive” for music which is fully open (meaning it can easily be mirrored by anyone with enough disk space).

Top 10,000 Songs by Popularity
https://annas-archive.li/blog/spotify/spotify-top-10k-songs-table.html

Теперь главное - сделать бекап регулярным!

#prog

Для #java есть JEP 401: Value Classes and Objects (Preview). Value-объекты в данном случае — это объекты, у которых отсутствует идентичность. Это полезно, поскольку для многих классов, которые просто объединяют несколько полей вместе для удобства (например, LocalDateTime, или условной Point в графическом движке), наличие идентичности, отличной от совокупности значений, не имеет большого смысла.

На практике идентичность у объектов Java существует из-за того, что под них выделяется память в куче и, соответственно, у них есть уникальный адрес. Отсутствие такой идентичности позволяет генерировать более разумную реализацию оператора ==, а также делать то, что в JEP называется "heap flattening": изменение представление объекта, ссылки на который вместо хранения адреса выделенной памяти хранят значения полей объекта.

Всё это звучит хорошо, но, к сожалению, данная идея страдает от существующих элементов дизайна Java.

Первая — это повальная нуллабельность. Даже value-классы должны иметь возможность быть null, и это означает, что даже для сжатого представления один бит в ссылке должен отводиться под null-флаг. Как пишут сами авторы, массив из Integer, например, может хранить значения прямо в ссылках, но так как численные значения Integer занимают 32 бита и ещё один бит должен отводиться под null-флаг, на практике значения элементов массива будут занимать минимум по 64 бита. Это всё ещё выигрыш по сравнению с тем, что есть сейчас, поскольку это позволяет избежать индирекции на указателях и выделения 64 бита на заголовок каждого объекта в куче, но это всё ещё расточительно. Авторы явно признают эту проблему, и в разделе про дальнейшую работу есть ссылка на Null-restricted value class types JEP, но это пока лишь черновик.

Вторая проблема (которая, справедливости ради, была неочевидна индустрии на момент создания Java) — это отсутствие отслеживания алиасинга/перекрытия ссылок. В JEP авторы пишут:

Heap flattening must maintain the integrity of data. A flattened reference must always be read and written atomically, or it could become corrupted. On common platforms, this limits the size of most flattened references to no more than 64 bits.

Иными словами, выгоды от избегания аллокаций коснуться только очень маленьких объектов — особенно с учётом обязательного null-флага и паддинга под него. Но тут вообще стоит задать вопрос: зачем в принципе стоит требование атомарности обновлений ссылок? Атомарность нужна для того, чтобы избежать разрыва значений при одновременных обновлениях. Соответственно, если одновременных доступов нет, атомарность не требуется! Если бы в Java был механизм, который позволяет удостоверять, что доступ к значению уникален и остаётся уникальным в течение всего времени, пока значение остаётся достижимым (по крайней мере, для записи — многопоточное чтение безопасно и без атомарных операций), можно было бы использовать неатомарные операции для обновлений и избежать таким образом ограничений на размеры value-объектов. Можно считать это ещё одним примером к Fixing the next 10000 aliasing bugs, где инвариантом выступает целостность данных, и плюсом в копилку преимуществ отслеживания алиасинга для различных языков программирования.

Вышла новая Lua - https://www.opennet.ru/opennews/art.shtml?num=64476

https://github.com/luarocks/luarocks/issues/1215 - а вот тикет про MIMT в пакетнике для Lua, всем пофиг. Похоже, они так 11 лет назад починили битый сертификат у репы - https://github.com/luarocks/luarocks/issues/286. К слову, сертификат всё ещё битый

А вот, например, меня спрашивают, почему я написал свой пакетник на python, а не на lua, я даже растерялся с ответом - https://github.com/stal-ix/ix/issues/803

Новый шедевр от Фабриса - https://github.com/bellard/mquickjs

Как и всегда у него, 20к строк хорошо обфусцированного кода в одном файле - https://github.com/bellard/mquickjs/blob/main/mquickjs.c

https://www.opennet.ru/opennews/art.shtml?num=64483

https://www.phoronix.com/news/Meta-SCX-LAVD-Steam-Deck-Server

"An interesting anecdote from this month's Linux Plumbers Conference in Tokyo is that Meta (Facebook) is using the Linux scheduler originally designed for the needs of Valve's Steam Deck... On Meta Servers. Meta has found that the scheduler can actually adapt and work very well on the hyperscaler's large servers"

TL;DR - опять Миша не разобрался.

https://lpc.events/event/19/contributions/2099/attachments/1875/4020/lpc-2025-lavd-meta.pdf

Не "Meta использует тот же шедулер, что работает на Steam Deck", а "Meta взяли фреймворк шедулеров на ebpf, и творчески запилили свой вариант", #sched_ext #ebpf

Пару лет назад писал, что в gdb нельзя печатать thread local переменные, с musl и/или статической сборкой - https://xn--r1a.website/itpgchannel/1420.

И, ура, это починили!

https://www.opennet.ru/opennews/art.shtml?num=64463

"На платформе Linux реализована встроенная возможность доступа к локальным переменным потоков (Thread-Local Storage, TLS), используемая при отсутствии библиотеки libthread_db. Возможность доступна для архитектур x86_64, aarch64, ppc64, s390x и riscv при сборке с GLIBC или MUSL"

На КДПВ видно, что это реально работает!

(бонусом на КДПВ можно увидеть эмодзи в gdb, сука, глаза бы мои не видели это непотребство)

#prog #article

Advent of code optimizations — сборник декабрьских статей, по одной в день (в обратном хронологическом порядке), демонстрирующих на отдельных небольших примерах различные оптимизации компиляторов. Написано Мэттом Годболтом (да-да, тот самый, который godbolt.org).

https://www.opennet.ru/opennews/art.shtml?num=64485

"Исследователи из компании CodeRabbit проанализировали 470 pull-запросов (350 - созданные AI, 150 - написанные вручную) в открытых проектах на GitHub и пришли к выводу, что в изменениях, сгенерированных AI-ассистентами, присутствует в 1.7 раза больше значительных дефектов и в 1.4 раза больше критических проблем, чем во вручную написанном коде. В среднем в сгенерированных через AI pull-запросах присутствовало 10.83 проблем, в то время как в созданных вручную изменениях данный показатель составил 6.45.

При рассмотрении отдельных категорий проблем, в созданном AI коде было в 1.75 раз больше логических ошибок, в 1.64 раза больше проблем с качеством и сопровождаемостью кода, в 1.56 больше проблем с безопасностью и в 1.41 раз больше проблем с производительностью. Дополнительно отмечается, что в генерируемом через AI коде в 1.88 раз выше вероятность некорректной обработки паролей, в 1.91 раз - небезопасного предоставления доступа к объектам, 2.74 раза - межсайтового скриптинга (XSS) и в 1.82 раза - небезопасной десериализации данных. При этом в написанном людьми коде в 1.76 раз больше орфографических ошибок и в 1.32 раза больше ошибок, связанных с тестированием"