Вторая глава той WIP книжки. Глубоко погружаются в пучину безумия color spaces. Красиво и интересно, но сложно и мало кому на самом деле нужно :)

#color #ui

Подвернулся интересный вопрос на StackExchange: почему сообщения времен второй мировой содержали приписку «This telegram must be closely paraphrased before being communicated to anyone»?

#cryptography #encryption

Разбирают, как так получилось, что asyncio с нами в python уже 10 лет, а его до сих пор неохотно используют. Причин масса. И ущербность языка и рантайма, и разработчики, которым «сложно думать асинхронно», и сложности поддержки sync и async API в одной и той же библиотеке. В целом хорошо характеризует средний уровень этой экосистемы.

#python #async

Эссе с размышлениями на тему: «Do the simplest thing that could possibly work». Рассуждают по сути о том, когда можно делать просто, а не правильно и масштабируемо, и почему это может быть хорошо.

#code #programming #async

Вот вроде бы и прикольный пост, а вроде бы и странный. Сначала чел намазывает, какие Unix pipes чудесные: изоляция, композиция, асинхронность, универсальные стандартные потоки для данных. Потом говорит, что это уже устарело, так уже не носят: всё линейно и очень ограничено. Настоящим пацанам хочется и структурированных данных (кстати, в Windows в PowerShell вроде что-то такое наплодили? Типа объекты на выходе CLI программ?), и всяких fan-in/fan-out, и чтобы все это с очередями и GC. Я с ужасом представляю себе баш скрипт со всем этим добром. И искренне не понимаю, что же они там такое в баше делают, что им это все потребовалось.

#unix #shell #cli

Emacs невероятно крут и бесконечно гибок, но в то же время за годы оброс удивительными проблемами, которые не так-то просто решить. Поэтому многим приходит в голову шальная мысль Emacs переписать. Но ведь хочется весь Elisp API сохранить, чтобы существующие пакеты работали. И тут начинается: кастомные мутабельные строки, которые поддерживают диапазон символов шире, чем большинство ЯП, своя особая система регулярок, таблицы для самых разных вещей, каждую из которых юзер может менять, и т.д.

#emacs #editor

Сравнивают Docker с Podman и всячески нахваливают второго: rootless, pods, systemd service / k8s YAML generation, и т.д.

#docker #podman

Брайан Керниган про историю Unix. Если не из первых, то из вторых рук, так сказать. Кайф, и секция с вопросами в конце хорошая.

#talk #history #unix

URL-shortener, но только ссылки в результате выглядят как жёсткое порево!
- Вот ссылка на goo.gl: https://cam-xxx.live/phishing/adware_module.exe?endpoint=flood&id=a67b&user=impersonate
- А вот на одну страничку в вики: https://cheap-bitcoin.online/scanner-controller/adware_dropper_tool.exe?id=9d87&noscript=overwrite&useragent=track
Кайф же, ну?) Там всё чисто, честное слово!

#url #internet #humor

Тут описывают, почему SQLite - вполне себе хороший и даже правильный выбор для многих веб-приложений / серверов. Разбирают плюсы и минусы. Рассказывают, чего можно ожидать.

#sqlite #db

Интересный доклад от мэйнтейнера HTMX. Выкладывает свои мысли и идеи о том, как писать веб-приложения, которые могут жить десятилетиями, не требуя особой поддержки. Удивительным образом мы оказались в мире, в котором самая первая веб страница всё ещё работает везде и доступна каждому, а нативные мобильные и десктоп приложения перестают работать очень быстро и постоянно чего-то требуют.

#talk #web #browser

Интересный документ попался.
self-reliant programmer manifesto.
Немного спорный, но интересный.

#rant #programming

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

#talk #keyboard #hardware

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

#talk #python #history

Один из разработчиков KDE рассказывает, как работать с негативным фидбеком. Но на самом деле рассказывает, через какое дерьмо проходят бесплатные мэйнтейнеры FOSS.

#talk #feedback #oss

Тут вот интересная драма развернулась. Чел, опоздав в merge window, прислал в Linux Kernel патч вокруг RISC-V. В этом патче в какой-то общий (non-RISC-V-specific) header просочился helper make_u32_from_two_u16. На что Линус стриггерился и проехался катком по бедному пареньку: мол, не надо нам этого вообще, напиши явно inline. Проблема в том, что если писать inline, легко допустить неприятных ошибок. Вот тут разбирают подробнее. Я затрудняюсь выбрать сторону, и там, и там валидные аргументы. Если бы писал сам, скорее всего написал бы с helper. Кто что думает?

#linux #kernel