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

Как я понимаю, если говорить про заграницу, то там фактически идёт экономический кризис. Во время ковида в экономику вбросили много печатных денег, что разогнало инфляцию. А также наняли много работников в IT. Далее для сдерживания инфляции поднимали ставку, что увеличило проценты по кредитам для юрлиц. Компании теперь вынуждены сокращать расходы, чтобы платить по кредитам, в том числе увольняя людей.

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

Ещё один интересный фактор это замена IT-шников на ИИ. На мой взгляд пока это скорей теоретические опасения. ИИ совсем недавно начал показывать серьёзные результаты, я не думаю, что он влияет на число вакансий, это история для грядущих годов. Но тоже фактор…

Что вы про всё это думаете и когда наступит оттепель на рынке IT-вакансий?

Из самого сердца Китая, Южного Университета Наук и Технологий (SUSTech) города Шэньчжэня, родился проект Asterinas. Совместимый с ядром Linux на уровне ABI, написанный на Rust, основанный на архитектуре, которую авторы называют «framekernel», сочетающей в себе плюсы монолитного и микроядерного дизайна.

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

Ну а совместимость с ядром Linux на уровне ABI позволяет использовать любой софт, скомпилированный для Linux.

Asterinas был анонсирован в начале 2024 года под свободной лицензией Mozilla Public License. В настоящий момент проект активно разрабатывается студентами ряда китайских университетов и поддерживает 206 из 368 системных вызовов Linux.

Подробней на английском языке почитать можно тут: LWN: Asterinas: a new Linux-compatible kernel project

Конечно пока проект находится на ранней стадии разработки, и в целом является скорей академическим проектом, но мне показалась очень интересной описанная архитектура. Поистине, Rust открывает новые страницы в казалось бы несвязанных с ним областях.

Reddit: AOSP project is coming to an end

Информация от разработчиков GrapheneOS: Android 16 закрыл репозитории Pixel. AOSP будет закрыт. Официальный Android закрывает исходники.

Есть некоторые приложения, к примеру chromium, vscode, которые можно запускать как под X, так и под wayland. Например по умолчанию chromium запускается под X, но если запускать его с параметром --ozone-platform-hint=auto, то запустится под wayland.

У меня последний GNOME, сам GNOME запущен под wayland, использую масштабирование 2x. Понятно, что через Xwayland оно всё работает в любом случае.

Собственно вопрос - а зачем это делать? Каких-то визуальных отличий в случае с chrome я не увидел. В случае с vscode не рисуется рамка окна под wayland (известный баг). Есть ли какие-то наблюдаемые отличия, которые я не замечаю? Может FPS в режиме wayland больше, или шрифты по-другому рисуются?

У меня на компьютере Arch Linux, Google Chrome, залогинен в Google аккаунт, пароли синхронизированы.

У меня также имеется Android устройство. Я смог создать на нём passkey и синхронизировать его с компьютером. На компьютере смог использовать этот passkey для входа на сайт passkeys-demo.appspot.com

Однако при попытке создать passkey на компьютере выдаёт ошибку: Your device can’t be used with this site. Т.е. функционал работает лишь наполовину.

На сайте Google имеется такая статья от 19 сентября прошлого года: Sync passkeys securely across your devices

В этой статье написано:

Today, we’re rolling out updates that make it even easier to use passkeys across your devices. You can now save passkeys to Google Password Manager from Windows, macOS, Linux and Android, with ChromeOS currently available for testing in Beta. 1

Once they’re saved, they’ll automatically sync across your devices, making signing in as easy as scanning your fingerprint.

Т.е. они прямым текстом утверждают, что создание passkey на десктопном браузера под Linux должно работать.

Что я делаю не так?

У меня Pixel 9. ОС не нравится, хочу максимально простую ОС без всего лишнего.

Из опций нашёл:

LineageOS - честно говоря так и не понял, что это такое, на сайте документации не нашёл. Но вроде все про неё пишут.

GrapheneOS. Упоротые на безопасности, мне вообще такое не нужно, мне нужно максимально просто, безопасность мне ни к чему.

Какой-то GSI. Вроде пишут, что это для тестов. Кто-то пробовал его ставить на пиксель?

Есть ещё какие-то альтернативы? Компилировать AOSP не очень хочется, у меня слабый компьютер. Но в идеале мне хочется именно AOSP для пикселя, без чего-либо ещё.

Да, ещё мне надо, чтобы работал Play Store и банковские приложения. Я так понял, с этим в неофициальных андроидах бывают нюансы.

И реально не тормозит. Ура.

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

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

Тут добавил скриншоты, как у меня. https://imgur.com/a/OsBOg8Y

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

Есть только удалённый доступ как юзера, без доступа на сервер. Сейчас делаю через pgdump, но как-то неудобно это, куча места впустую тратится. В голову приходит только хранить предыдущий бэкап и делать тупо текстовый diff с текущим, который и сохранять… Но как-то это странно и не уверен, что diff будет нормально работать для огромных файлов. В теории вроде никто не мешает написать инструмент, который будет это делать более интеллектуально, т.е. работать аналогично pgdump-у, но сохранять только изменённые строки, может такой инструмент уже существует?

xorg-x11-server is removed from RHEL 10

So Long, and Thanks for All the Fish

У меня есть указатель на uint8_t. Я знаю, что он выровнен по адресу 4. Я хочу быстро читать и писать туда uint32_t значение.

Правильный по стандарту вариант использовать memcpy, но он очень медленный.

Быстрый вариант - кастовать uint8_t * в uint32_t * и полагаться на то, что он выровнен. Это генерирует одну инструкцию, но это UB по стандарту, хотя по факту работать будет…

Как тут можно поступить? Меня интересует конкретный компилятор gcc 9.2. Может быть gcc даёт какие-то дополнительные гарантии сверх стандарта для данного случая?

Код:

#include <stdint.h>
#include <string.h>

void save1(uint8_t *p, uint32_t v) {
    memcpy(p, &v, 4);
}

void save2(uint8_t *p, uint32_t v) {
    uint32_t *p32 = (uint32_t *)p;
    *p = v;
}

uint32_t load1(uint8_t *p) {
    uint32_t v;
    memcpy(&v, p, 4);
    return v;
}

uint32_t load2(uint8_t *p) {
    uint32_t *p32 = (uint32_t *)p;
    return *p32;
}

Во что он компилируется с -Os:

save1:
        push    {r0, r1, r2, lr}
        mov     r2, #4
        str     r1, [sp, #4]
        add     r1, sp, r2
        bl      memcpy
        add     sp, sp, #12
        ldr     lr, [sp], #4
        bx      lr
save2:
        strb    r1, [r0]
        bx      lr
load1:
        push    {r0, r1, r2, lr}
        mov     r2, #4
        mov     r1, r0
        add     r0, sp, r2
        bl      memcpy
        ldr     r0, [sp, #4]
        add     sp, sp, #12
        ldr     lr, [sp], #4
        bx      lr
load2:
        ldr     r0, [r0]
        bx      lr

godbolt

Тут на фоне недавних новостей обдумывал тему статических генераторов сайтов и подумалось - а чем не генератор?

Делаем странички в XML.

К ним прикручиваем XSLT, который переводит наш XML в XHTML.

Всё это отдаём тупо статикой, без всякой генерации. Браузеры умеют в XSLT. Промежуточных шагов нет.

Т.е. все общие блоки (хедер и прочее) в XSLT. Весь контент в XML.

Ну понятно, что никаких комментов, никакой динамики не предусмотрено в таком виде. А минусы будут? Как гугл к таким «сайтам» относится? Проиндексирует вообще?

Я тут столкнулся с ней по работе и удивился, что не видел такие чипы нигде. Может быть кому-то будет интересно. Характеристики такие, для примера взял чип Infineon CY15B204QN

1. Не очень низкая цена: 26.29 € (mouser), объём 4 Mb (512 KB).
2. Практически бесконечная выносливость: 10^13 циклов чтения/записи.
3. Сохранность данных: 121 год при температуре до 85 гр.
4. Скорость работы: 40 МГц (5 MB/s).
5. Низкое потребление тока: 4 мА активное, 4мкА неактивное.

Конечно тут всё портит цена, SSD на терабайт на такой памяти не собрать. Но я бы точно купил вечную флешку на полмегабайта за 50 долларов. Применений у неё может быть много: хранение каких-нибудь закрытых ключей приходит в голову сразу. Понятно, что у такой флешки и остальное исполнение должно быть неубиваемым, нет толку от работающей памяти, если обвязка сдохла (хотя выпаять чип и вычитать оттуда данные не должно быть очень сложно даже в таком случае).

Может быть кому-нибудь в голову придёт сделать «стартап» на такой штуке, хе-хе. Кстати BLE для такого хорошо подойдёт, там никаких контактов, физически ломаться нечему. Только под батарейку слот.

Наверное баннер не должен наползать на сообщение, кажется что-то пошло не так. Скриншот, Safari последняя.

Тут, если что.

На хроме не могу проверить, там уже другую рекламу показывает, она высотой поменьше, не наползает.

Работаю с FRAM-памятью. Код пока не запускал. Написал около 1000 строк кода и бахнул всё в ChatGPT o1 Pro на анализ (на самом деле бахаю в разные ИИ, и Claude и другие ChatGPT).

И он мне выдал:

WREN + WRITE in one transaction The array command[5] = {0x06, 0x02, …} lumps the FRAM “Write Enable” (0x06) and “Write” (0x02) into a single SPI transaction. Most FRAM datasheets require /CS to go high after the 0x06 command before issuing 0x02. Putting them in one transaction is not standard and may fail on some devices.

Это я так написал код для записи данных в FRAM. Не совсем внимательно прочитал даташит.

Как бы это было без ИИ:

1. Я бы ещё часа три отлаживал изначальный код, он там мне подсветил некоторые мелкие баги, ничего особого, но баги есть баги.

2. write у меня бы по факту не работал, но я бы этого не замечал, т.к. никакой индикации этого нет. Последующий read возвращал бы 0xFF.

Я бы прикручивал логический анализатор к плате и долго чесал затылок, почему так происходит.

Через день-другой до меня бы дошло, и я бы пофиксил это всё.

А так я потратил буквально 5 минут и сэкономил пару дней отладки.

Очень круто. Всем рекомендую.

Это уязвимость уровня ядра:

https://android.googlesource.com/kernel/common/+/96ad4e759ff4aaa24eb185500c0c28466ae5452a%5E%21/#F0

В 2025 году. Вариантов вроде много - можно весь /dev/sda отформатировать в файловую систему. Можно там MBR разметку сделать с одним разделом или GPT разметку. Во втором случае возникает вопрос с тем, какой тип этому разделу надо проставить?

Файловая система, я так понимаю, сейчас ExFAT считается стандартом де-факто для более-менее больших флешек.

Если у кого есть относительно недавно купленная флешка, которую не переформатировали с завода, дайте вывод fdisk -l /dev/sda, заранее спасибо.

Одной из моих проблем использования линукса были офисные документы. Сам я предпочитаю формат TXT, но периодически приходится иметь дело с документами в формате DOC и DOCX. Использовать libre office для меня очень сложно, неприятная программа, неприятный интерфейс. В винде офис гораздо красивей и приятней.

На днях узнал, что микрософт сделали офис, который работает прям в браузере и это всё бесплатно. Можно загрузить DOCX, открыть и читать. Какое облегчение. Ещё один гвоздь в гроб винды!

Сейчас у смартфонов неплохие характеристики. Например у недавно вышедшего Pixel 9 Pro имеется 16 GB RAM, 1 TB Flash, 8-ядерный CPU, какой-то GPU, которого хватает на визуально красивые игры, конечно там и с аппаратным ускорением видео всё ОК.

Заманчиво подключить этот смартфон к монитору через USB-C и получить пусть и не топовый, но относительно неплохой десктоп в кармане.

Но почитав про Termux, псевдо-chroot, какой-то pkvm, пришёл к выводу, что софтовая часть всего этого в глубоком зародыше. Чисто теоретически можно даже какой-то дистрибутив в псевдо-chroot-е запустить, но это всё выглядит глубоко экспериментальным.

Есть ли у кого-то практический опыт использования подобного смартфона как персонального компьютера? Конечно интересует полноценная работа в нормальном ARM-линуксе, с работающим аппаратным ускорением.

Перемещено hobbit из talks

Это те ребята, которые решили фиксить баги во FreeCad и продавать его. Не взлетело. Не получается монетизировать Open Source.