Про переписывание истории

В баше (а точнее, в GNU Readline, который используется башом), есть довольно странная фича: историю команд можно редактировать!

Делается это так:
* нажимаем клавишу ↑, доматываем до команды, которую хотим отредактировать
* редактируем команду
* нажимаем клавишу ↓, доматываем до конца
* готово :)

Наглядную демонстрацию можно видеть на видео выше.

Я на эту «фичу» неумышленно натыкался много раз, и, сам того не зная, редактировал историю. А потом недоумевал, почему у меня при вызове history часть строк оказывались пустыми.

Как это отключить? Можно почитать, например, здесь. Если коротко, то надо в домашней папке создать файл с названием .inputrc и поместить в него такие строчки:

$include /etc/inputrc
set revert-all-at-newline on

🔎 Смотрите какую красоту показали. Анализатор трафика, использующий под капотом eBPF - kyanos...

- Сайт: https://kyanos.pages.dev/
- Github: https://github.com/hengyoush/kyanos

Позволяет получить данные о сетевом взаимодействии конкретного процесса для http трафика, redis запросов и трафика сервера БД mysql.

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

#tui #kyanos #фидбечат

Еще про проклятые фичи баша

https://yossarian.net/til/post/some-surprising-code-execution-sources-in-bash

tl;dr: вот эта функция на баше при передаче «правильного» аргумента может привести к выполнению произвольного кода:

function guess() {
  num="${1}"
  if [[ "${num}" -eq 42 ]]
  then
    echo "Correct"
  else
    echo "Wrong"
  fi
}

Мораль проста: не пишите на баше не передавайте в bash-скрипты недоверенные данные

​Кажется в одном из выпусков про DWDM упоминалосья что не надо смотреть на оптические панели, не зная мощности сигналов в оптике, а то панель может посмотреть обратно на тебя.

Я в целом согласен с основной мыслью поста, за исключением слов должны. Это open source, тут никто никому ничего в общем случае не должен 🌝

Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков). 

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

Рынок должен начать смотреть на Kubernetes как на Linux Kernel. Что я имею в виду? В трезвом уме сисадмин маленькой или средней компании вряд ли станет говорить на работе, что не нужно использовать дистрибутив Linux — мол, сейчас он возьмет ядро и соберет свой дистрибутив. Так просто не принято: все понимают, что надо выбирать готовый дистрибутив, подходящий под конкретный набор задач. Да, есть и универсальные дистрибутивы, которые более-менее успешно могут использоваться под разные задачи, однако помимо дистрибутивов общего пользования (generic purpose), есть и куча специфических дистрибутивов вроде того же Talos Linux, Kali Linux, VyOS, DSL, SLAX, которые заточены под конкретные виды задач.
. . .
Многие ли инженеры четко и полноценно понимают, что там скрыто в недрах Linux Kernel, какие крутилки ядра применены в том или ином дистрибутиве Linux? А все потому, что рынок принял дистрибутив как некий эталон юнита с минимальной единицей бизнес-ценности, дробить эту абстракцию до уровня ядра или отдельных компонентов ядра просто нет смысла. Конечно, крупные компании собирают свои дистрибутивы — например, тот же Microsoft уже в новой технологической истории сделал Azure Linux. Однако большинству компаний это не нужно.

Тут возникает вопрос: а как поменять это мышление? Что для этого должно произойти? На мой взгляд, для полноценного запуска этого тектонического сдвига необходимы следующие процессы:

- Рабочие группы CNCF (TAG App Delivery, Technical Oversight Committee, а также мейнтейнеры и главные спонсоры Kubernetes) должны запустить дискуссии по этой теме. Обсудить перспективы и угрозы, в итоге выработав некую продуктовую стратегию. Потому что в итоге Kubernetes как продукт должен претерпеть достаточно серьезные изменения — одно дело, когда разрабатывается полноценное ПО и совсем другое, когда разрабатывается компонент, пусть и центральный. 

- TAG App Delivery, Technical Oversight Committee должны начать говорить с рынком и транслировать в него послание о том, что необходимо много платформ, чтобы были альтернативы. А также создать документы и технические условия (или инициировать формирование новой рабочей группы), позволяющие максимально упростить процесс создания платформы (собственно, Kubernetes как продукт должен сфокусироваться именно на том, что он становится центральным компонентом сторонней платформы).

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

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

- CNCF и другие open source-организации должны брать такие проекты под свое крыло и помогать им развиваться, а также выделять под продвижение такого подхода временные слоты на ключевых конференциях, которые они организуют (речь, например, о Kubecon).

Неизбежное будущее Kubernetes: почему оркестратор должен пойти по пути Linux Kernel
https://habr.com/ru/companies/aenix/articles/865238/

Канал автора @glina_nauchit

9 декабря 2024 года вышло расширение GitHub Skyline CLI для визуализации в ASCII достижений на платформе для разработки, а также экспорта этих данных для 3D-печати. Исходный код проекта GitHub Skyline (gh-skyline) написан на Go и опубликован под лицензией MIT.

#разработка

Мне это было сложно осознать, но Microsoft выпустили библиотеку для конвертации офисных файлов в маркдаун. То есть да, можно брать вордовый поток сознания и переводить в чистый, понятный, структурированный и внятный маркдаун без всех этих скачков форматирования и прочей чуши.
А можно не вордовский, а прям презентаху, и её тоже разложит в красивый вид. И прям парси её, анализируй её и вообще кайф.
https://github.com/microsoft/markitdown

https://github.com/facundoolano/software-papers
#github #softwareengineer

A Simple ELF

Let's write a simple program for Linux. How hard can it be? Well, simple is the opposite of complex, not of hard, and it is surprisingly hard to create something simple. What is left when we get rid of the complexity from the standard library, all the modern security features, debugging information, and error handling mechanisms?

https://4zm.org/2024/12/25/a-simple-elf.html
#ELF

Для подведения итогов года сохраняем шрифт для TODO-списков, поднимающий мотивацию, заряжающий на выполнение задач и дающий +50 к АНЖУМАНЯ

https://github.com/private-face/begit

https://blog.smidt.dev/posts/0003/
#ebpf #go

Один важный инсайт, который косвенно пришел ко мне из Кложе-мира, но в целом универсален: никому не нужны ваши программы. Всем нужны данные.

Грубо, никому не нужна программа-просмотрщик PDF. Зато всем нужна сама пэдээфка. И гугль-докс никому не нужен, нужны только тексты, которые в нем написаны. Уйдет гугль-докс — будут писать в ворде, уйдет ворд — придумают что-нибудь еще.

Звучит контринтуитивно — вроде мы так мучаемся, пишем эти самые программы, функции, UI какие-то придумываем, пользователей заставляем пользоваться. Условно, 90% усилий и 90% времени проходит в программах и за написанием программ.

И все же. Программы сами по себе никому не нужны. Они нужны как способ трансформации данных. Взять что-то на вход, обработать, поменять, выплюнуть что-то новое и все. После этого твоя программа снова никого не интересует. Может ее удалят, может забудут, может поменяют на конкурента, или может она сломается с обновлением. А может завтра снова запустят — ху ноуз?

Программы скоротечны — могут пожить год, ну пять, некоторые совсем исключительные дотягивают до тридцатника. А данные — вечны. Данные переносятся между компьютерами, операционными системами, поколениями.

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