Life Pattern

Category: Uncategorized

  • The Unnatural Selection

    We often describe capitalism with the cliché of a big fish eating smaller fish. One predator, one victim.

    But that’s not really how many modern markets work.

    In biology, success creates resistance. If a predator grows too large, it starves. If it wipes out too much prey, the system collapses and resets. Physics enforces a hard speed limit on size.

    In parts of today’s economy, success does the opposite.

    Corporations don’t have bodies. They don’t suffer the same metabolic drag. As they grow, size often makes them stronger: capital attracts more capital, scale lowers costs, and distribution reinforces itself. At a certain point, these organizations stop behaving like organisms and start behaving more like massive objects in space.

    Gravity is a better metaphor than predation.



    What looks like competition from the outside often isn’t. Multiple brands may appear independent, but many quietly orbit the same center—shared ownership, infrastructure, or incentives. To customers, it feels like choice. Structurally, it’s consolidation. Less ecosystem, more accretion disk.

    This doesn’t require villains or conspiracies. It’s what happens when positive feedback loops operate without strong counterforces.

    You see the pattern everywhere: How many CPU brands today? Disk drives? Operating systems? Airlines, brewers, payment networks, web-hosting groups?

    Not every collection of brands is an ecosystem. Some are closer to gravity wells.

  • The Container Runtime Family Tree

    From cli to kernel:

    graph TB
    subgraph "User/Orchestration Layer"
        Docker[Docker CLI]
        K8s[Kubernetes/Nomad]
        Podman[Podman CLI]
    end

    subgraph "Container Runtime Interface - CRI"
        CRI[Container Runtime Interface<br/>Kubernetes API Standard]
    end

    subgraph "High-Level Container Manager Layer"
        containerd[containerd<br/>Used by Docker/Kubernetes]
        CRIO[CRI-O<br/>Used by OpenShift/Red Hat]
        PodmanDirect[Podman + conmon<br/>Daemonless Engine<br/>Direct OCI Invocation]
    end

    subgraph "OCI Runtime Specification"
        OCI[Open Container Initiative<br/>Standard Runtime Interface]
    end

    subgraph "Standard OCI Runtimes<br/>Namespace Isolation"
        runc[runc<br/>Reference Implementation<br/>⚡⚡⚡ Fastest - 🛡️ Basic]
        crun[crun<br/>C-based, Lightweight<br/>⚡⚡⚡ Fastest - 🛡️ Basic]
        runhcs[runhcs<br/>Windows Containers<br/>⚡⚡⚡ Fast - 🛡️ Basic]
    end

    subgraph "Sandboxed OCI Runtimes<br/>User-Space Kernel"
        gVisor[gVisor runsc<br/>User-space Kernel<br/>⚡⚡ Moderate - 🛡️🛡️ Strong]
        nabla[nabla-containers<br/>Unikernel<br/>⚡⚡ Moderate - 🛡️🛡️ Strong]
    end

    subgraph "VM-Based OCI Runtimes<br/>Hardware Virtualization"
        Kata[Kata Containers<br/>OCI-compliant runtime<br/>⚡⚡ Good - 🛡️🛡️🛡️ Highest]
    end

    subgraph "Kata Hypervisor Backends<br/>Pluggable VMM Layer"
        KataQEMU[QEMU<br/>Full-featured hypervisor<br/>All device support<br/>⚡⚡ Good - 🔹 50-100MB]
        KataCH[Cloud Hypervisor ⭐<br/>Modern Rust-based VMM<br/>Balanced performance<br/>⚡⚡⚡ Fast - 🔹 20-40MB]
        KataFC[Firecracker<br/>Minimal serverless VMM<br/>Limited features<br/>⚡⚡⚡ Fastest - 🔹 5-15MB]
    end

    subgraph "Alternative: Direct Firecracker<br/>⚠️ Not OCI Runtime"
        FCContainerd[firecracker-containerd<br/>containerd shim<br/>AWS Lambda backend<br/>❌ No Podman support]
    end

    subgraph "Host Kernel / Hypervisor Layer"
        HostStd[Linux Kernel<br/>Standard containers]
        HostVM[Linux Kernel + KVM<br/>VM-based containers]
    end

    %% Docker path
    Docker -->|uses| containerd
    
    %% Kubernetes paths
    K8s -->|CRI API| CRI
    CRI -->|implements CRI| containerd
    CRI -->|implements CRI| CRIO
    
    %% Podman path (bypasses CRI)
    Podman -->|direct| PodmanDirect
    
    %% High-level to OCI
    containerd -->|OCI Runtime Spec| OCI
    CRIO -->|OCI Runtime Spec| OCI
    PodmanDirect -.direct call.-> OCI

    %% OCI to standard runtimes
    OCI --> runc
    OCI --> crun
    OCI --> runhcs

    %% OCI to sandboxed runtimes
    OCI --> gVisor
    OCI --> nabla

    %% OCI to VM-based runtimes
    OCI --> Kata

    %% Kata to hypervisor backends
    Kata -->|hypervisor=qemu| KataQEMU
    Kata -->|hypervisor=clh ⭐| KataCH
    Kata -->|hypervisor=fc| KataFC

    %% Alternative Firecracker path (not OCI)
    containerd -.special shim.-> FCContainerd

    %% Standard runtimes to host
    runc --> HostStd
    crun --> HostStd
    runhcs --> HostStd
    gVisor --> HostStd
    nabla --> HostStd

    %% VM-based runtimes to host with KVM
    KataQEMU --> HostVM
    KataCH --> HostVM
    KataFC --> HostVM
    FCContainerd --> HostVM

    %% Styling
    classDef userLayer fill:#FFB366,stroke:#333,stroke-width:2px
    classDef criLayer fill:#90EE90,stroke:#333,stroke-width:3px
    classDef managerLayer fill:#FF9999,stroke:#333,stroke-width:2px
    classDef ociLayer fill:#90EE90,stroke:#333,stroke-width:4px,stroke-dasharray: 5 5
    classDef runtimeStd fill:#FFD700,stroke:#333,stroke-width:2px
    classDef runtimeSandbox fill:#87CEEB,stroke:#333,stroke-width:2px
    classDef runtimeVM fill:#DDA0DD,stroke:#333,stroke-width:2px
    classDef vmmLayer fill:#E6B3FF,stroke:#333,stroke-width:2px
    classDef vmmRecommended fill:#90EE90,stroke:#333,stroke-width:3px
    classDef alternative fill:#FFE4B5,stroke:#333,stroke-width:2px,stroke-dasharray: 3 3
    classDef hostLayer fill:#696969,stroke:#333,stroke-width:2px,color:#fff

    class Docker,K8s,Podman userLayer
    class CRI criLayer
    class containerd,CRIO,PodmanDirect managerLayer
    class OCI ociLayer
    class runc,crun,runhcs runtimeStd
    class gVisor,nabla runtimeSandbox
    class Kata runtimeVM
    class KataQEMU,KataFC vmmLayer
    class KataCH vmmRecommended
    class FCContainerd alternative
    class HostStd,HostVM hostLayer

  • Тук ли е вече бъдещето, в което AI ще ни казва да си рестартираме компютъра?

    Колко пъти ви се е случвало да чакате с часове на телефона, само за да ви кажат да си рестартирате компютъра?

    С подобряването на AI системите ще бъде все по-лесно да се осигури добра техническа поддръжка. Но какво значи “добра”?

    Нека обясня, за всеки случай, какво прави техническата поддръжка и къде AI може (или не може) да я замести в близките няколко години. По традиция, заради оптимизация на разходите, поддръжката е разделена на нива.

    Level 1: от “рестартирай компютъра” до “истински полезен техничар”

    Често клиентите се посрещат от хора, които нямат висока квалификация или опит, а следват инструкции.

    Ако са достатъчно многобройни, може и да отговарят бързо, но…

    a) Ако са по-неопитни, ниско платени и т.н. са доста безполезни, защото не разбират по-сложните въпроси, а само повтарят “моля рестартирайте си компютъра” или copy & paste random docs. Ако не са достатъчно много и са претоварени – още по-зле. Могат да помогнат само в доста ограничен кръг ситуации и често просто си губите времето. Това сме го виждали дори при support на големи доставчици на интернет и колокация с месечни договори за десетки хиляди пари на месец.

    b) Ако са по-опитни, може и да са донякъде полезни, може да дадат правилните стъпки, но понякога твърде бавно, не адаптирани за конкретния клиент. Бива, но не са проактивни. Текущите AI на практика са достигнали, че дори надхвърлят това ниво, но не са добре интегрирани все още.

    Една очевидна възможност е, да се захрани AI с всички предишни support cases (RAG, fine tuning) и да подава на служителя готови отговори с бутони за редактиране и одобрение.

    c) Перфектният L1 е техничар с опит, който познава продукта в детайли, не ти губи времето с излишни и грешни стъпки и знае кога да ескалира към по-горно ниво. Ясни инструкции, предугажда какво се случва и какво трябва да се направи. Трудно е да се задържат хора на такава позиция, защото обикновено ги повишават или те си намират друга работа.

    Level 2: от “повишен прекалено рано” до “директен контакт с дев тима”

    a) Посредственият L2 е някой, когото са повишили от L1 твърде рано. Или някой, който е претоварен и няма време и мотивация да свърши работата както трябва. Понякога бърз, понякога бавен. Понякога върши добра работа, понякога налучква.

    b) Отличният L2 е компетенен, има задълбочен опит с продукта, може директно да си говори с разработчиците, админите и въобще когото трябва. Знае как да възпроизведе клиентските проблеми, знае как да заобиколи known issue и т.н. Вярвам, че много скоро ще може да се постигне чрез колаборация от умерено мотивиран и компетентен L2 human + AI tools.

    L3/Developer: злато, ако стигнеш до тях

    Това често са хора, които са участвали в създаването на продукта. Може да променя системата и да оправя бъгове в отговор на потребителски проблеми. Може да отнеме известно време, но реакцията е… gold. Супер висока полезност, ако се добереш до такъв.

    Architect / CTO / Founder-level

    Човекът (хората), които са измислили системата. Познават подробно бизнес логиката, технологиите, историята и бъдещето. Може да променят дизайна на системата при нужда (вкл. в следствие на потребителски оплаквания).

    В типичните компании е на практика почти невъзможно да стигнеш до такъв. Евентуално след множество оплаквания от различни потребители, скандали… ако си голям клиент.

    Bonus: Can you actually get to CTO/CEO?

    Обикновено не. Освен, ако не си много голям клиент, инвеститор или инфлуенсър, който да ги подкара в социалните мрежи 🙂

    В по-малки компании или стартъпи има някакъв шанс, но в големи… good luck reaching Bezos или шефа на A1 (примерно).

    Support TierОписаниеAI-onlyHuman-onlyHuman + AI
    L0 – „Моля, рестартирайте“Без разбиране, просто повторение на шаблони✅ GPT-3.5? ниво (2022)——
    L1 – слабCopy/paste от база знания, слабо разбиране✅ GPT-4o? (2024)——
    L1 – окЧесто правилни отговори, но понякога налучкване, недостатъчно адаптация⚠️ Claude Sonnet 3.7? (2025)✅🔥
    L1 – отличенПознава продукта, преценява кога да ескалира, ясни и адаптивни отговори❌ Почти (Reasoning models), но не стабилно (2025-2026)✅👍
    L2 – посредственЧастично полезен, неуверен, понякога налучква❌ 2027?✅⚠️ (2025 подпомага само)
    L2 – добърВъзпроизвежда проблеми, намира workarounds, разбира системата дълбоко❌ 2028?✅⚠️ (2025 подпомага само)
    L3 / DeveloperМоже да направи fix, разбира кода, имплементира❌ 2029?✅⚠️(2025 подпомага само)
    Architect / CTO / CEOПознава цялата картина, взема решения, променя посока❌✅❌

    Предвид моят личен опит (или трябва да кажа сблъсък?) с поддръжката на най-различни компании — от малки до огромни, от фитнес до технологии — навлизането на AI е положителна тенденция за потребителите. Ще съм доволен да мога да получавам по-бърза и адекватна информация и вярвам, че точно това и ще се случи. AI напредва със зашеметяваща скорост, не го мързи, няма проблеми с мотивацията, не се уморява и не му се спи, не боледува, наличен е 24/7 и е по-евтин от човек.

    За съжаление, може много хора да изгубят работата си :'( Така е било и с индустриализацията разбира се, но имам усещането, че този път е по-различно. Ще бъде по-бързо, всеобхватно и непредвидимо.

    Какво мислите вие – ще успее ли AI да замени човешката поддръжка?