Linux ی که opinion داره، وقتی opinion هاش coherent باشن، دیگه contradiction نیست.

linux design opinion product devops

Omarchy تابستون launch شد و 37signals داره کل شرکت رو تو یه بازه‌ی سه‌ساله روش migrate می‌کنه. برداشت واضح اینه که DHH کلاً Linux partisan شده و شرکت داره دنبالش می‌ره. برداشت واقعی جالب‌تره. Omarchy با opinion های visible shipped می‌شه، تو بازاری که تاریخش با opinion های hidden برده، و دقیقاً این جفت‌بندی visible و opinionated ـه که این پست درباره‌شه.

اون contradiction

Linux قراره یه toolkit ی neutral باشه. distribution هایی از Linux که سهم گرفتن، این کار رو با نگرفتن position انجام دادن. “just works” ی Ubuntu، “always current” ی Fedora، “immutable by default” ی Silverblue؛ هرکدوم یه personality لو می‌دن، ولی آروم. هرکدوم حاضرن یه default ی shipped کنن که با preference ی کاربر disagree داره، با این فرض که کاربر وقت نداره alternative رو یاد بگیره. Omarchy اولین distribution ـیه که دیدم توش personality خودش lead feature ـه: aesthetic-first، opinionated، و loud opinionated. marketing page با کلمه‌ی “opinionated” شروع می‌شه. README با کلمه‌ی “opinionated” شروع می‌شه. blog post های DHH درباره‌ش با کلمه‌ی “opinionated” شروع می‌شن. اون کلمه داره کار واقعی می‌کنه.

contradiction اون بخشیه که launch رو جالب می‌کنه. distribution های Linux قراره flexible layer باشن؛ اون substrate ی.stack هستن. این‌که substrate position بگیره، غلط حس می‌شه، همون‌طوری که یه package manager ی که position می‌گیره غلط حس می‌کنه. instinct اینه: هرچی تو stack پایین‌تر می‌ری، باید neutral تر باشی. Omarchy این instinct رو می‌شکنه، و این پست درباره‌ی اینه که چرا شکستنش کار می‌کنه.

Omarchy واقعاً چی‌کار می‌کنه

Arch Linux به‌علاوه‌ی Hyprland به‌علاوه‌ی یه toolchain ی curated. اون stack ـه. تکه‌ی جالب Hyprland ـه، یه tiling window manager که بدون login screen، بدون menu bar، بدون notification، بدون file manager shipped می‌شه. هیچ‌کدوم از این‌ها. بازآرایی DHH اون بخشیه که کار رو انجام می‌ده. اون gap defect نیست؛ precondition ی personalization ی واقعی ـه، چیزی preconfigured نیست که باهاش بجنگی. هزینه‌ش حدود ده ساعت setup ی اولیه‌ست. پاداشش اینه که هر behavior ی که بعداً کاربر باهاش کار می‌کنه، behavior ی ـیه که خودش انتخاب کرده، و default ی برای undo کردن نیست.

راست، این جمله‌ست که من رو قانع کرد. “هیچ‌کدوم preconfigured نیست که باهاش بجنگی.” این جمله کل argument رو خلاصه می‌کنه. یه default ی preconfigured فقط default نیست؛ یه direction ـه که کاربر باید consciously باهاش contradict کنه تا کاری رو که واقعاً می‌خواد انجام بده. Hyprland direction نداره. فقط choice های کاربر رو داره. معامله ده ساعت در ازای ownership ـه، و ownership چیزیه که کاربر بهش value می‌ده چون قراره سال‌ها داخل سیستم بمونه.

چرا framing ی visible-opinion مهمه

یه opinion ی hidden، برای هرکسی که نویسنده‌ش نیست، شبیه accident می‌مونه. Hyprland با هیچی shipped می‌شه، و تو لحظه‌ای که screen روشن می‌شه می‌بینیش. chrome ی باهوشی برای decode کردن نیست، menu bar ی برای کشف کردن نیست، notification daemon ی برای یاد گرفتن نیست. opinion روی screen ـه لحظه‌ای که screen روشن می‌شه. این visibility همون چیزیه که opinion رو به contract تبدیل می‌کنه. کاربر commit می‌شه به اون ده ساعت. کاربر flexibility رو بعداً می‌گیره. هردو نیمه visible ان.

مقایسه‌ش کن با Ubuntu. “just works” ی Ubuntu از بیرون شبیه “always current” ی Fedora ـه، ولی با reasoning های متفاوت به همون نقطه می‌رسن. Ubuntu ی GNOME با یه مشت extension ی opinionated shipped می‌کنه (dock، snap store، systemd network default ها) و هیچ‌وقت به کاربر نمی‌گه که این‌ها choice ان. Fedora ی GNOME ی تمیز shipped می‌کنه و کاربر همون choice ها رو با خوردن به دیوار کشف می‌کنه. Silverblue immutable shipped می‌کنه و کاربر immutability رو با خوردن به یه دیوار ی دیگه کشف می‌کنه. هرکدوم از این distribution ها opinion داره. هرکدوم از اون opinion ها پشت default ی پنهان شده که شبیه fact می‌خونه. کاربر باید opinion رو on faith قبول کنه.

opinion های visible با non-believer تماس رو survive می‌کنن چون non-believer می‌تونه ببینه چی sign up کرده. کاربری که Hyprland رو boot می‌کنه و نمی‌خواد ده ساعت setup کنه، فوری exit ramp داره؛ install تو چند دقیقه reversible ـه، و کاربر می‌دونست. کاربری که Ubuntu رو boot می‌کنه و snap نمی‌خواد، تا بیست ساعت باهاش نجنگه نمی‌فهمه snap opinion ـه یا bug. opinion های hidden از accident ها قابل تشخیص نیستن. opinion های visible contract ان.

این کجا generalize می‌شه

همون rule برای هر product ی که default هاش personality ش رو حمل می‌کنه صادقه. یه CI pipeline ی opinionated از یه pipeline ی flexible بهتره وقتی opinion ها تو template ها visible ان. یه Homebrew formula ی opinionated از یه formula ی neutral بهتره وقتی opinion ها تو فایل formula مستندن. یه deployment tool ی opinionated از یه tool ی neutral بهتره وقتی opinion ها تو deploy log ها visible ان. distinction ی visible/hidden همون چیزیه که survive می‌کنه. جنس opinion مهم نیست؛ visibility کل بازیه.

خواننده باید با یه test ی قابل انتقال بره. وقتی یه default می‌بینی، می‌تونی بفهمی چرا اون default ـه؟ اگه آره، product تو sense ی visible opinionated ـه، و opinion contract ـه. اگه نه، product تو sense ی hidden opinionated ـه، و hidden sense همون ـه که under load می‌شکنه. هر product یه جا opinionated ـه؛ سوال اینه که کاربر می‌تونه opinion ها رو audit کنه بدون این‌که product رو ترک کنه یا نه.

اون trap

trap اینه که Omarchy رو به‌عنوان یه داستان Linux بخونی. نیست. یه داستان product ـه، و زاویه‌ی Linux لایه‌ی dating ـه. همون argument رو می‌شد درباره‌ی Rails تو 2004 زد (یه web framework که روی convention ها position گرفت و position ها رو تو directory layout visible کرد)، درباره‌ی Postgres extension ها تو 2025 (یه database ecosystem که author های extension، assumption هاشون رو کنار install مستند می‌کنن)، درباره‌ی refusal ی iPhone از stylus تو 2007 (یه hardware opinion که لحظه‌ی shipped شدن device visible بود، بدون driver، بدون setting)، درباره‌ی modularity ی Framework laptop امروز (یه hardware opinion که first time ی که کاربر bottom panel رو باز می‌کنه visible می‌شه). هرکدوم product ی ـه که position گرفته. هرکدوم از اون position ها روی سطحه. هیچ‌کدوم hide نمی‌شه.

ecosystem ی Linux پونزده سال quietly داره argument ی “آیا opinion های visible shipped کنیم یا نه” رو می‌بازه. argument این بود که کاربر neutrality می‌خواد، platform نباید editorial کنه، substrate باید invisible باشه. argument غلط بود، ولی مدتی یه غلط respectable بود، چون alternative ها هم عمدتاً hidden بودن. Omarchy جالبه چون alternative ها رو visible می‌کنه. argument نمی‌زنه که substrate باید editorial کنه. editorial می‌کنه، و به کاربر اجازه می‌ده editorial رو ببینه. این یه argument ی دیگه‌ست، و قوی‌تر.

قانون و test

همون opinionated default وقتی reasoning ش visible ـه feature ـه، و وقتی reasoning ش hidden ـه bug ـه. دفعه‌ی بعد که دست می‌بری به سمت یه tool که default هاش personality ش رو حمل می‌کنه، یه سوال بپرس: personality visible ـه؟ اگه آره، tool durable ـه. اگه نه، tool یه روزی می‌شکنه، چون کاربر بعدی با opinion ی hidden می‌جنگه و می‌بازه. opinion های hidden accident هایی ان که منتظر non-believer ان. opinion های visible contract هایی ان که منتظر sign up ان.

Omarchy جالبه چون این سوال رو جواب دادنش رو آسان می‌کنه، تو بازاری که جواب تاریخش “نه، فقط به ما trust کن” بوده. این‌که خود Omarchy جنگ سهم بلندمدت رو می‌بره یا نه، یه سوال ی دیگه‌ست، و یه سوال ی که ادعا نمی‌کنم جوابش رو بدونم. argument این نیست که Omarchy برای شما درسته. argument اینه که opinion های visible به شکلی durable ان که opinion های hidden نیستن، و ecosystem ی Linux یه دهه و نیم وقت صرف shipped کردن hidden ها کرده. argument اینه که substrate اجازه داره position بگیره. argument اینه که position ها وقتی کاربر می‌تونه ببینه‌شون قوی‌ترن.

$ cat OBSERVABILITY .md
· 7 دقیقه مطالعه

pipeline قدیمی ~۴۷هزار span از دست داده بود. نداده بود. ما اشتباهی می‌شمردیم.

تو یه parallel-run validation، یه مقایسه‌ی side-by-side از span count به‌ازای هر service نشون داد که pipeline جدید حدود ۰.۲٪ از span ها رو تو یه پنجره‌ی ۶۰ دقیقه‌ای از دست می‌ده. اگه به‌عنوان regression تو pipeline جدید خونده می‌شد، یه rollback trigger می‌کرد. اگه درست خونده می‌شد، یعنی pipeline قدیمی تو یه پنجره‌ی چندثانیه‌ای ده‌ها هزار ردیف duplicate داشت insert می‌کرده. storage layer روی چیزی که داره count می‌شه unique constraint نداره؛ واحدی که به‌عنوان 'count' expose می‌کنه همون واحدی نیست که operator فکر می‌کنه.

observability clickhouse verification troubleshooting devops
$ cat DOCKER .md
· 5 دقیقه مطالعه

یادداشت گفته بود image غلطه. image درست بود. سه تا چک هم تأیید کردن.

یه یادداشت توی knowledge bundle پروژه گفته بود image فقط amd64 هست و ممکنه روی Graviton کار نکنه. سه تا چک مستقل هم تأییدش کردن. image فقط amd64 نبود، و یه build arm64 بدون هیچ تغییری تو source جواب داد. یه ادعایی که سه بار verify شده، خطرناک‌ترین شکل یه ادعای غلطه.

docker arm64 verification knowledge-management devops
$ cat KAFKA .md
· 8 دقیقه مطالعه

درباره‌ی یه سیستم live سه تا چیز infer کردم. دوتاش غلط بود.

تو یه هفته سه بار درباره‌ی یه migration زنده یه ادعا کردم، از روی یه config file، یه name prefix، یا یه template، و دوبار اون ادعا غلط بود. artefact و سیستم live دو تا دید از یه چیزن، و می‌تونن به دلایلی با هم match کنن که artefact نمی‌تونه بگه‌شون. فقط یکی‌شون حقیقته.

kafka opentelemetry terraform troubleshooting devops