DEV Community: Krishna Jha

Why China Is Doing So Good in AI... And Why Open Models Like Qwen and Kimi Might Matter More Than We Think

Krishna Jha — Tue, 08 Sep 2026 12:26:56 +0000

For the longest time, the AI race seemed pretty simple...

America was winning.

OpenAI had GPT.

Google had Gemini.

Anthropic had Claude.

NVIDIA was selling the GPUs that basically everyone wanted to train AI.

And China?

China was supposed to be catching up...

But then something interesting happened.

DeepSeek happened.

Qwen kept getting better.

Kimi started getting serious.

And suddenly, people around the world started realizing something...

China wasn't just "catching up" anymore.

It was becoming one of the most important players in AI.

And personally, I think the most interesting part of China's AI industry isn't even necessarily its biggest models...

It's the open models.

Or, more accurately in many cases, open-weight models.

Models like Qwen, DeepSeek, Kimi, GLM, and others are doing something that I think could become extremely important in the next few years...

They are making powerful AI accessible.

Not just through an API...

But directly to developers, companies, researchers, and basically anyone who wants to build something with them.

And honestly... I think that could be a much bigger deal than people realize.

First... America and China are playing slightly different games

Right now, most of the biggest American AI companies have a pretty straightforward business model.

They build a ridiculously powerful model...

They put it on their servers...

And you pay to use it.

You want GPT?

Use OpenAI's servers.

You want Claude?

Use Anthropic's servers.

You want Gemini?

Use Google's infrastructure.

It's simple.

The company owns the model.

The company owns the servers.

The company controls access.

And, obviously, the company charges you.

This isn't necessarily bad. In fact, it makes complete sense.

Training frontier AI models costs billions of dollars. Running them costs money too. Companies need to make that money back somehow.

But China's AI ecosystem has been moving in another direction too...

Build powerful models...

Release the weights...

Let developers build on top of them.

And that's where things get interesting.

Because once you release a capable model, it stops being just your product.

It can become infrastructure.

Someone can run it locally.

Someone can fine-tune it.

Someone can build an AI assistant around it.

Someone can put it inside a coding tool.

Someone can deploy it inside a company.

Someone can literally build an entire startup around it.

That is a completely different kind of strategy.

Qwen is probably one of the best examples of this

I've personally found the Qwen ecosystem extremely interesting.

Alibaba isn't just trying to build one giant chatbot and call it a day...

There are different models.

Different sizes.

Different capabilities.

Different models for different use cases.

And that's important because the future of AI probably isn't going to be...

«Everyone opening one website and talking to one gigantic AI model.»

AI is going to be everywhere.

Inside operating systems.

Inside coding tools.

Inside apps.

Inside companies.

Inside robots.

Inside servers.

Inside phones.

Inside cars.

And for most of those things, you don't necessarily need the biggest and smartest AI model on the planet.

You need something that is...

Fast
Cheap
Good enough
Reliable
Customizable
Possible to run on your own infrastructure

That last one is huge...

Because companies don't always want their data leaving their infrastructure.

Governments definitely don't want to depend entirely on another country's AI companies.

And developers don't always want to pay an API bill forever.

That's where models like Qwen become extremely powerful.

And then there's Kimi...

Kimi is another reason why I don't think DeepSeek was just some random one-time event.

Moonshot AI and other Chinese labs are showing that there is an actual ecosystem developing in China.

Multiple companies are competing.

Multiple companies are training models.

Multiple companies are trying different approaches.

And that's important.

Because people often look at this as...

«America vs China.»

But there is another competition happening...

China vs China.

Alibaba.

DeepSeek.

Moonshot AI.

Z.ai.

MiniMax.

Baidu.

ByteDance.

And many more.

All of them want to build better models.

Better coding models.

Better reasoning models.

Better agent models.

Cheaper models.

Faster models.

That competition matters.

Because competition creates pressure...

And pressure creates innovation.

If you're the only company in a country building AI, you can take your time.

But if five other companies are about to release something better than you...

Well...

You move faster.

DeepSeek changed the entire conversation

Before DeepSeek, there was this assumption that frontier AI was basically impossible without infinite money.

You needed billions of dollars.

Thousands and thousands of GPUs.

Massive data centers.

The newest NVIDIA hardware.

And basically the infrastructure of Google or Microsoft.

Then DeepSeek showed up...

And suddenly, everyone started paying attention.

Now, I'm not saying DeepSeek magically solved AI.

And obviously, there are debates about training costs, hardware, compute, and all of that.

But that's not even the most important part.

The important part was what DeepSeek proved...

Chinese AI labs could release models good enough to make the entire industry pay attention.

And after DeepSeek...

People started looking more seriously at everything else coming out of China.

Qwen.

Kimi.

GLM.

MiniMax.

Suddenly, China wasn't just this country everyone expected to follow behind the US.

It was becoming one of the biggest sources of powerful AI models in the world.

Especially open ones.

And I think that's where the real story begins...

Open AI creates something closed AI cannot easily create...

An ecosystem.

Think about Linux.

Linux didn't become important because one company forced everyone to use it.

It became important because developers could build on it.

Companies could build on it.

Researchers could experiment with it.

Entire companies could create products around it.

Now think about Android.

Google created the base.

Then Samsung built on it.

Xiaomi built on it.

OnePlus built on it.

Thousands of developers built apps for it.

And suddenly, you don't just have an operating system...

You have an ecosystem.

I think open AI models could work similarly.

Imagine a powerful model like Qwen being available to developers.

One developer builds a coding assistant.

Another builds a local AI chatbot.

Someone else builds an AI operating system.

A company fine-tunes it using their internal data.

Another company uses it for customer support.

Someone builds an AI agent.

Someone builds a robot around it.

And eventually...

That model becomes infrastructure.

This is the part that I think people underestimate.

The company that builds the smartest AI isn't necessarily the only company that wins.

The company whose AI becomes the foundation for millions of other things could win too.

And China is also making AI cheap...

This is probably one of the biggest reasons Chinese models are becoming popular.

Because let's be honest...

Most people don't need the smartest AI in the universe.

A company doesn't necessarily care if GPT is 3% smarter than another model.

What they care about is...

«Can it do the job?»

And then...

«How much does it cost?»

Imagine two models.

Model A is slightly better.

Model B is almost as good for your use case but costs significantly less.

If you're just using AI occasionally...

Maybe you choose Model A.

But what if you're processing millions of requests?

What if you're building an AI product?

What if you're running thousands of AI agents?

Suddenly, cost becomes extremely important.

And I think this is where Chinese companies have understood something very important...

AI isn't only a research competition anymore... It's becoming an economics competition.

The question isn't just...

«Who has the smartest model?»

It's also...

«Who can give people powerful AI at the lowest possible cost?»

That is a completely different competition.

And China seems very serious about winning it.

The US restrictions might have created an unexpected result...

The United States has restricted China's access to some of the most advanced AI chips.

And obviously...

That creates serious problems for Chinese companies.

I'm not going to pretend otherwise.

Access to advanced GPUs is extremely important.

NVIDIA has an incredible ecosystem.

And the United States still has major advantages when it comes to frontier compute and AI infrastructure.

But there is another side to this...

Restrictions can create pressure.

And pressure forces efficiency.

If you don't have unlimited access to the newest hardware...

You have to figure out how to do more with what you have.

You need better architectures.

Better training techniques.

Better inference efficiency.

Better memory management.

Better software.

Better optimization.

Basically...

You can't just throw more GPUs at the problem.

You have to become smarter.

Again, I'm not saying export restrictions helped China.

They clearly created major challenges.

But they may have also pushed Chinese AI companies to focus heavily on efficiency.

And that efficiency is now becoming one of their strengths.

China also has something incredibly important...

Scale.

China has...

A massive population
Huge technology companies
Massive manufacturing
A huge number of engineers
Massive cloud infrastructure
A huge consumer technology market
Serious government interest in AI

That creates an environment where AI isn't just another startup trend.

It's becoming infrastructure.

AI can be integrated into...

Manufacturing.

Robotics.

Phones.

Apps.

Education.

Transportation.

Government systems.

Companies.

And that's important because the future AI race might not be won by whoever builds the best chatbot.

It might be won by whoever actually deploys AI everywhere.

Think about it...

Building a powerful AI model is one thing.

Actually getting millions or billions of people to use AI is something completely different.

And China is extremely good at scaling technology.

I think the future could look a little like Android vs iPhone...

Not literally...

But philosophically.

On one side, you could have extremely powerful closed AI systems.

OpenAI.

Anthropic.

Google.

These companies build the model...

They run the infrastructure...

And you access the AI through their products or APIs.

It's controlled.

It's polished.

And probably extremely powerful.

Then on the other side...

You have powerful open-weight models.

Qwen.

DeepSeek.

Kimi.

GLM.

Llama.

And many others.

You can download them.

Run them yourself.

Fine-tune them.

Deploy them.

Build products around them.

And I don't think one side is going to completely destroy the other.

Both will probably exist.

Some people will always want the absolute smartest AI possible.

Others will want control.

Privacy.

Customization.

Lower costs.

Or independence from a specific company.

And those people will choose open models.

The really interesting part is the Global South...

I think this could become huge.

The US and Europe can afford expensive AI infrastructure.

But what about everyone else?

India.

Africa.

Southeast Asia.

Latin America.

Smaller countries.

Smaller companies.

Universities.

Individual developers.

Not everyone can afford expensive API calls forever.

But an open model?

That's different.

You can download it.

Run it locally.

Host it on your own server.

Customize it.

Fine-tune it for your language.

Build your own product around it.

And if Chinese models become the default AI infrastructure in developing countries...

That would be massive.

Not because China forced anyone to use them...

But because people chose them.

Because they were cheap.

Accessible.

Capable.

And customizable.

That's a completely different kind of technological influence.

And honestly...

I think this possibility is heavily underestimated.

But China isn't winning everything...

Let's be clear here...

China still has serious challenges.

The United States still has huge advantages.

Especially when it comes to...

Advanced AI chips
NVIDIA's ecosystem
Frontier compute
Venture capital
Cloud infrastructure
Some of the world's best AI research labs
The biggest closed frontier models

And there are also concerns about Chinese models.

Not every model described as "open" is actually fully open source.

Sometimes the model weights are available...

But the training data isn't.

Sometimes the full training process isn't reproducible.

There are also concerns about censorship and how some models handle politically sensitive questions.

So no...

Chinese AI isn't some perfect open-source paradise.

Far from it.

But pretending that China is still massively behind everyone else is also becoming increasingly difficult.

The gap is getting smaller.

And in some areas...

There might not even be a meaningful gap anymore.

My prediction for the future...

I think the next few years are going to be absolutely insane.

And I think three things are going to happen...

Closed models will probably remain at the absolute frontier

OpenAI.

Anthropic.

Google.

And maybe other companies will continue building the most powerful AI models.

They have massive amounts of compute.

Massive data centers.

The latest chips.

Huge research teams.

If you want the absolute best AI model for the most difficult tasks...

Closed models might continue leading for quite some time.

Open models will become good enough for almost everything

And this...

This is where things become interesting.

If an open model is 50% as good as GPT...

Most people will still use GPT.

If it's 70% as good...

Same thing.

But what happens when an open model becomes 90% as good?

What happens when it becomes 95% as good for your particular use case?

And you can run it yourself?

Customize it?

Control your own data?

Avoid paying API costs forever?

Now companies start asking questions...

«Why are we paying so much?»

«Why are we sending our data somewhere else?»

«Why are we dependent on one company?»

«Why can't we just run this ourselves?»

That's where open models become dangerous for closed AI companies.

They don't necessarily need to become better than GPT or Claude.

They just need to become...

Good enough.

Cheap enough.

Fast enough.

And accessible enough.

And honestly...

They're getting there very quickly.

The AI race will become an ecosystem race...

Right now, everyone is obsessed with benchmarks.

Who's number one?

Who scored higher?

Which model can solve more problems?

And yeah...

That stuff matters.

But eventually, I think ecosystem will matter even more.

Imagine this...

One model is 3% smarter.

But another model has millions of developers building tools around it.

Thousands of companies deploying it.

Governments using it.

Startups fine-tuning it.

Researchers experimenting with it.

Who is actually winning?

The answer becomes complicated.

Because technology leadership isn't just about having the best product.

It's also about...

Adoption
Developers
Cost
Infrastructure
Distribution
Integration
Ecosystem

And China is becoming very good at those things.

So... Why is China doing so well in AI?

I think it's because of a combination of things...

Massive engineering talent.

Huge technology companies.

Internal competition.

Government support.

Scale.

Efficiency.

A massive domestic market.

And increasingly...

A willingness to release powerful models and let developers build on top of them.

That last part could become extremely important.

Because the real AI war might not be...

«OpenAI vs DeepSeek.»

Or...

«America vs China.»

The bigger question might be...

What happens when powerful AI becomes cheap enough and accessible enough that almost anyone can use it?

What happens when a startup can download a model instead of paying millions for API access?

What happens when governments can run their own models?

What happens when your laptop can run an AI that would have required a data center a few years ago?

What happens when open models become the foundation of millions of products?

I don't think we have the answers yet...

But I do think one thing is becoming clear.

China isn't just trying to catch up anymore.

It's helping shape what the next generation of AI could actually look like.

America might continue building some of the smartest AI models in the world...

But China could play a huge role in making powerful AI available to everyone else.

And if that happens...

The AI race won't be decided by one model.

It won't be decided by one benchmark.

And it definitely won't be decided by one company.

It will be decided by ecosystems...

And honestly...

I don't think we've even seen the real AI war yet...
Maybe it isn't far away tho.

Building KOS: A Journey Through Zero Dependencies (And the Bugs That Taught Me Everything)

Krishna Jha — Tue, 08 Sep 2026 11:43:38 +0000

I didn't set out to reject go get. I just wanted to build something clean. But somewhere between the first snapshot corruption and the fourth complete rewrite, I realized: zero dependencies wasn't a constraint. It was a feature.

This is the real story of KOS—what I built, what broke, why I fixed it the way I did, and how you can use it yourself.

What is KOS?

KOS is a portable, encrypted version control system. It's not trying to replace Git. It's trying to be something Git isn't:

Single file: Everything lives in one main.go (~2000 lines)
Zero dependencies: 100% Go standard library
Encrypted: AES-256-CFB with HMAC-SHA256 integrity
Portable: Runs from a USB stick, no installation
Simple: kos init → kos save "message" → kos view

It stores your project snapshots in a global vault (~/.kos-global/) indexed by UUID. No Git databases. No complex merge logic. Just snapshots and timelines.

Getting Started: How to Use KOS

Installation

git clone https://github.com/kosmoscpp/kos
cd kos
make install  # Linux/Mac
# or: build.bat  # Windows

That's it. One binary. No dependencies to install. You can even compile it on a machine without Go and ship the binary to another machine.

Basic Workflow

Initialize a project:

kos init
# ✓ Initialized empty KOS repository in /home/user/.kos-global/abc123...
# Project UUID: abc123-def456-ghi789-...

Create snapshots:

kos save "Initial commit"
kos save "Added authentication"
kos save "Fixed bug in auth flow"

View your timeline:

kos view

Output:

╔══════════════════════════════════════════════════════════╗
║                     KOS TIMELINE                         ║
╚══════════════════════════════════════════════════════════╝

  ● abc1e2f1 ┃ Jan 08, 14:32 (just now) ┃ Fixed bug in auth flow
  │           ┃  42 files
  │
  ● a2d3f4b5 ┃ Jan 08, 14:15 (15 mins ago) ┃ Added authentication
  │           ┃  41 files
  │
  ● 8c7e9a0b ┃ Jan 08, 12:00 (2 hours ago) ┃ Initial commit
  │           ┃  40 files
  └── (End of history)

Compare snapshots:

kos diff abc1e2f1 a2d3f4b5
# Shows: + Added (0), ~ Modified (2), - Deleted (0)

kos diff abc1e2f1 a2d3f4b5 auth.go
# Shows line-by-line diff for auth.go

Tag releases:

kos tag v1.0
kos tag stable abc1e2f1  # Tag a specific snapshot

Restore your work:

kos checkout abc1e2f1                    # Restore entire snapshot
kos checkout abc1e2f1 src/main.go        # Restore single file
kos checkout v1.0                        # Restore by tag
kos checkout HEAD~3                      # Go back 3 commits

Encrypted snapshots:

kos save --encrypt "Secret credentials"
# Password: ****
# Confirm: ****
# 🔐 Saved encrypted snapshot: Secret credentials (15 files)

kos share abc1e2f1  # Export as snap_abc1e2f1.tar.gz.enc
# Can email/USB/cloud this file. Recipient loads with:
kos load snap_abc1e2f1.tar.gz.enc
# Password: ****

Project management:

kos projects           # List all projects in global store
kos rename "my-blog"   # Rename current project
kos stats              # Show project statistics
kos search "refactor"  # Search commit messages

The Bugs (And Why They Matter)

This is where it gets real. Because building from scratch means building through everything.

Bug #1: HEAD Recognition Fails (The Identity Crisis)

Early on, I implemented KOS to share and diff by snapshot ID. Simple, right?

kos share HEAD        # Error: Snapshot 'HEAD' not found
kos diff v1.0 v1.1   # Error: Snapshot 'v1.0' not found

Only raw IDs like 18d03947 worked. Tags and HEAD references were rejected.

The root cause: I wrote separate lookup functions that did direct ID matching instead of using a reference resolver:

// WRONG: Direct lookup, doesn't handle special refs
func findSnapshot(id string) *Snapshot {
    for i := range manifest.Snapshots {
        if manifest.Snapshots[i].ID == id {
            return &manifest.Snapshots[i]
        }
    }
    return nil
}

The fix: I extracted reference resolution into a single function that handles all cases:

// CORRECT: Handles IDs, tags, HEAD, and HEAD~N
func resolveRef(ref string) *Snapshot {
    snaps := manifest.Snapshots
    if ref == "HEAD" {
        return &snaps[len(snaps)-1]
    }
    if strings.HasPrefix(ref, "HEAD~") {
        parts := strings.Split(ref, "~")
        var offset int
        fmt.Sscanf(parts[1], "%d", &offset)
        idx := len(snaps) - 1 - offset
        if idx >= 0 && idx < len(snaps) {
            return &snaps[idx]
        }
    }
    for i := range snaps {
        if snaps[i].ID == ref || snaps[i].Tag == ref {
            return &snaps[i]
        }
    }
    return nil
}

Now every command uses resolveRef(). Git-like references work everywhere.

What I learned: Centralize your logic. Don't repeat the same lookup in ten places. You'll catch edge cases faster and users won't hit weird state machines.

Bug #2: Encryption Produces Garbage (The Defer Nightmare)

Encrypted snapshots were completely corrupted. Trying to load them:

Error: unexpected EOF when trying to decrypt

I was encrypting an incomplete file.

The root cause: In cmdSave(), I used defer for everything:

// WRONG: Defer happens at function exit, but we encrypt before that!
file, err := os.Create(filepathTar)
defer file.Close()

gzw := gzip.NewWriter(file)
defer gzw.Close()

tw := tar.NewWriter(gzw)
defer tw.Close()

// ... add files to tar ...

if encrypt {
    encryptFile(filepathTar, encPath, password)  // File still open!
    // Defer hasn't run yet. File is incomplete. We're encrypting garbage.
}

The file was still being written when I tried to encrypt it. The tar writer hadn't flushed. The gzip writer hadn't compressed. The file wasn't closed.

The fix: Explicit close order before encryption:

// CORRECT: Close in dependency order before encryption
tw.Close()      // Tar closes first
gzw.Close()     // Gzip flushes compression
file.Close()    // File closes last

if encrypt {
    encryptFile(filepathTar, encPath, password)  // Now it's complete
}

This was a painful lesson in writer layering. Each writer depends on the one below it. You have to close from the top down.

What I learned: Don't let defer fool you into false security. When you have layered resources (writer → compressor → file), you need explicit, ordered cleanup. defer is great for simple cases. For complex ones, be explicit.

Bug #3: Encrypted Load Shows Zero Commits (The Skip Logic Backfire)

When loading encrypted snapshots:

kos load snap_abc123.tar.gz.enc
# ✓ Loaded encrypted project successfully!
# Commits: 0  ← WRONG! Should be 5

All the commits disappeared.

The root cause: The extract function had smart logic to skip .kos/ metadata when extracting:

// This is correct for normal use
if strings.HasPrefix(header.Name, ".kos/") {
    continue  // Skip metadata files
}

But the encrypted load code needed to read .kos/manifest.json to show how many commits existed. Since it was being skipped, the manifest was empty.

The fix: Use a different extraction function for encrypted loads that doesn't skip:

// extractFileFromTar reads directly from tar without skip logic
manifestContent, err := extractFileFromTar(decryptedPath, ".kos/manifest.json")
json.Unmarshal([]byte(manifestContent), &embeddedManifest)

Now encrypted snapshots preserve their full history.

What I learned: When you have branching logic (normal extract vs. encrypted load), they need different paths. Don't let one code path's assumptions break another's.

Bug #4: Password Masking Without x/term (The Syscall Journey)

I wanted masked password input (asterisks instead of plaintext). The easy way: golang.org/x/term. But that breaks zero dependencies.

So I went low-level. POSIX syscalls. SYS_IOCTL. Terminal state manipulation.

func readPassword() string {
    fd := int(os.Stdin.Fd())
    oldState, err := getTerminalState(fd)
    if err != nil {
        // Fallback if we can't control terminal
        var password string
        fmt.Scanln(&password)
        return password
    }

    newState := oldState
    newState.Lflag &^= syscall.ECHO  // Disable echo
    setTerminalState(fd, newState)
    defer setTerminalState(fd, oldState)

    var password []byte
    buf := make([]byte, 1)
    for {
        n, err := os.Stdin.Read(buf)
        if err != nil || n == 0 || buf[0] == '\n' {
            break
        }
        if buf[0] == 127 || buf[0] == 8 {  // Backspace
            if len(password) > 0 {
                password = password[:len(password)-1]
                fmt.Print("\b \b")  // Visual backspace
            }
        } else {
            password = append(password, buf[0])
            fmt.Print("*")
        }
    }
    return string(password)
}

func getTerminalState(fd int) (syscall.Termios, error) {
    var state syscall.Termios
    _, _, errno := syscall.Syscall6(
        syscall.SYS_IOCTL,
        uintptr(fd),
        uintptr(syscall.TCGETS),
        uintptr(unsafe.Pointer(&state)),
        0, 0, 0,
    )
    if errno != 0 {
        return state, errno
    }
    return state, nil
}

The tricky part: One wrong flag bit and users see their passwords on screen. The POSIX terminal model is finicky. This code works on Linux. Windows POSIX layer might have issues (but that's acceptable for a hackathon).

What I learned: Sometimes the "easy" dependency exists for a reason. But understanding the low-level mechanism? That's worth more than convenience. Now I know how terminal echo works. I know what TCGETS and TCSETS do. I know the bitfield layout of Termios.

Bug #5: The PBKDF2 Myth (And Correcting a Senior Engineer)

During review, someone asked: "Why SHA256 for key derivation instead of PBKDF2?"

They said: "It's in the standard library."

It's not.

crypto/pbkdf2 doesn't exist in stdlib. It's in golang.org/x/crypto, which is external. I had to correct them.

// This is what I use (stdlib)
func deriveKey(password string) []byte {
    hash := sha256.Sum256([]byte(password))
    return hash[:]
}

Felt weird correcting a senior engineer, but I was right. I triple-checked. go doc crypto/pbkdf2 returns nothing.

The choice: SHA256 is fast. PBKDF2 is slower (which is good for passwords—more resistant to brute force). But for a hackathon tool, the trade-off is acceptable. And it keeps zero dependencies.

What I learned: Don't assume. Don't trust memory. Actually verify what's in the standard library. And sometimes you do know things that others don't.

Bug #6: Ghost Projects In ~/.kos-global/ (The Cleanup Problem)

After months of testing:

ls ~/.kos-global/
abc123-def456-...
import-test-1
import-test-2
my-awesome-project-v1
my-awesome-project-v2
test-uuid-alpha
test-uuid-beta
... fifteen more orphaned directories

Each test run created new UUIDs. Each UUID got added to projects.json. But I never deleted old ones.

The root cause: During testing, I created projects, then deleted them locally, but their entries in projects.json remained. Then their directories stayed in the global store, orphaned and forgotten.

The fix: Had to manually:

rm -rf ~/.kos-global/test-uuid-*
rm -rf ~/.kos-global/import-test-*
vim ~/.kos-global/projects.json  # Remove orphaned entries

Then rebuild the index.

What I learned: Testing creates state. State accumulates. You need cleanup procedures or eventual garbage collection. In production, KOS should have a kos gc (garbage collect) command to clean up orphaned projects.

The Real Lessons

1. Writer Layering Matters

Gzip writes to a tar writer. The tar writer writes to a file. You have to close them in order: tar → gzip → file. Not all at once with defer.

2. Centralize Reference Resolution

Don't lookup snapshots in ten places. Do it in one place (resolveRef). Now HEAD works everywhere. Tags work everywhere. No weird edge cases.

3. Skip Logic Can Break Assumptions

Your extract function skips .kos/ files? That's correct for normal use. But encrypted loads need them. Different paths for different use cases.

4. Syscalls Teach You Real Things

Using golang.org/x/term is easy. Using syscall.Syscall6 with TCGETS is harder. But now I understand terminal echo at the OS level. That knowledge sticks.

5. Test State Accumulates

Build testing cleanup into your workflow. Delete projects between tests. Clean up projects.json. Otherwise you end up with fifteen ghost projects.

Why Zero Dependencies Was Worth It

I could have used:

github.com/urfave/cli for CLI parsing
golang.org/x/term for password masking
github.com/fatih/color for colors
github.com/google/uuid for UUIDs
github.com/sergi/go-diff for diffs

Each would have saved time on that specific feature. But:

I wouldn't have understood how any of them work
The binary would be much larger
The attack surface (for a security tool!) would be huge
I wouldn't have learned anything
Deployment would be more complex

Instead, I built a 4.2 MB binary that runs anywhere. I understand every line. I can audit it myself. I can deploy it to air-gapped networks. I can ship it on a USB stick.

How to Try It

# Clone and build
git clone https://github.com/kosmoscpp/kos
cd kos
go build -o kos .

# Initialize a project
mkdir my-project
cd my-project
../kos init

# Save some work
echo "Hello, KOS" > readme.md
../kos save "Initial commit"

# See the timeline
../kos view

# Make a change
echo "Hello, KOS with updates!" > readme.md
../kos save "Updated readme"

# View timeline again
../kos view

# Check what changed
../kos diff <snapshot-id-1> <snapshot-id-2>

# Restore a version
../kos checkout <snapshot-id>
cat readme.md  # Back to original

The Takeaway

Building KOS taught me that constraints aren't prison walls. They're focusing tools.

When I couldn't reach for go get, I had to understand my problems deeply. I had to learn about terminal I/O, writer layering, reference resolution, and encryption. I had to debug by understanding, not by reading someone else's code.

The result isn't just a tool. It's a tool I completely understand. It's a tool that's portable and secure. It's a tool that can run where nothing else can run.

That's worth the bugs. That's worth the deep dives. That's worth saying no to convenience.

Try KOS. Use it. Break it (please report issues). Learn from it.

And maybe, just maybe, build something with zero dependencies yourself. You'll be surprised what you learn when you can't go get your way out.

GitHub: kosmoscpp/kos

Quick Start:

git clone https://github.com/kosmoscpp/kos && cd kos && make install
kos init
kos save "My first snapshot"
kos view

That's it. No setup. No config. No dependencies. Just version control, zero friction.

Tagging Hackathon Raptors 🦖

RaptorFollow

We're the Hackathon Raptors Association, hosting regular #hackathons aimed at improving quality of life 🦖

My port of Python SemVer to Golang for my First Hackathon

Krishna Jha — Tue, 11 Aug 2026 03:18:28 +0000

Porting python-semver to Go on a phone, an old PC, and 41 hours

I'm Krishna, 18, in Class 12 prepping for JEE. When PORT MORTEM 2026 showed up, I didn't have a laptop for it. What I had was a Samsung A05 with Termux, and an old Core 2 Duo PC running Linux Mint Xfce that I could only get to the next morning.. But I really wanted to participate in a Hackathon, So my plan became: start on the phone doing whatever needs zero compute, move to the PC once I could sit at it, and don't pick a repo that punishes me for being resource constrained.

I picked python-semver. It parses and compares version strings like 1.2.3-alpha.1. No I/O, no state, just numbers and string rules.. It was also easy to understand, i.e. easy to get what this even does. The hackathons own examples pointed at node-semver as a good target for exactly this reason, python-semver is basically its Python sibling, and Python is the language I actually know well from every other project I've built.

Track: Open Pair, since Python to Go isn't one of the official pairings.

I did created the folder and all from my phone and used git from Termux to push the folder and asked Claude for what will I need to do, to prove the fuzzing and how to make a hashmap(my first time doing so!), after getting that, i added it to the push, also i generated that Personal Access Token (PAT) for 30 days, copied it and pinned it into my clipboard.
The next day, i did my first fuzzing test, then something broke..

What actually broke

I built a differential fuzz harness in Python that generates random and adversarial version strings, feeds them into both the real python-semver and my compiled Go binary, and diffs the results. First real run at 5000 cases came back with 5 mismatches. All of them involved a version where patch was 0 ;)

Turned out to be a bug in my own test harness, not the port. I'd set omitempty on the numeric JSON fields in the Go bridge, and omitempty silently drops any field equal to its zero value, including a legitimately zero patch number. So the bridge would send no "patch" field at all instead of "patch": 0, and my Python side read the missing key as None, which obviously didn't match 0. Removed omitempty from the numeric fields, reran, 0 mismatches ;)

The next one was a real bug. bump_build("8.35.21+V00") gave "V1" in my Go port but "V01" in python-semver. The original preserves the zero padded width when incrementing a numeric identifier inside a string, mine just parsed the digits to an int and reformatted plain, losing the padding. Fixed it by padding the result back to the original digit width instead of doing a plain integer to string conversion. Reran at 5000 cases, then again across a handful of different seeds to make sure it wasn't a one off. Stayed at 0 (Phew).

The mistake I had almost shipped

Part of this hackathon's rule is you hash the original repo's test suite at the start so nobody can quietly edit the tests to make their port pass. I did that on day one, but I cloned the default branch instead of pinning to a released version. Meanwhile my fuzz harness was running against whatever pip install semver actually gives you, which is the last published release, not main.

For most of the functions I ported this didn't matter because the code was identical between main and the release. It only became visible once I started porting next_version,which was not even in the original plan btw, but I decided to do it..which had been rewritten on main and wasn't in the published release yet. My hand traced expected output didn't match what pip's semver actually returned, and diffing the two sources side by side showed exactly why!

Fixed it by checking out the actual release tag (3.0.4) in my local clone, recomputing the test suite hash against that pinned commit, and updating the README to reference the correct commit hash. Everything I'd already fuzzed before that point was still valid since none of that logic had changed between main and the release, but the citation in my README was wrong until I caught it.

The decision I'd take back

Hashing against main instead of a pinned release tag on day one. It cost me nothing in the end because I caught it before submitting, but it easily could have been the kind of inconsistency a judge notices and starts poking at. Lesson learned: always pin to an actual release, never a moving branch, when you're making a provenance claim.

What I cut on purpose

I didn't port match(), the range syntax thing like >=1.0.0 <2.0.0. It's basically its own small parser, meaningfully more scope than everything else combined, and I'd rather ship something fully proven than something bigger with an unfuzzed corner. I did end up adding next_version() later since it turned out to just be composition of functions I'd already ported and proven, so the risk to add it was low.

Where it landed

Parse, compare, all three bump functions, bump_prerelease, bump_build, finalize_version, next_version, is_valid, all ported and passing differential fuzzing against the real python-semver 3.0.4 across roughly 30,000 generated cases and multiple random seeds, 0 mismatches on the final build.
And guess what?, it's 3.1x faster in parsing and a 363x faster in Comparing! (Ik it might be due to python being python and golang being golang, but ain't it amazing?)

I didn't had a mic for my PC, I had two options (for making the video), use DroidCam to record while speaking, but my PC setup is near street, so it would be noisy.. or (the one I did) Record audio somewhere quiet (it didn't came out that much quiet though), play it and start recording with it.

Repo's here: https://github.com/kosmoscpp/port-semver-go
Video:
https://youtu.be/SYA3pwTXHAw?si=gstEMU4o_qNAHDY9

Tagging Hackathon Raptors 🦖

RaptorFollow

We're the Hackathon Raptors Association, hosting regular #hackathons aimed at improving quality of life 🦖

I Built a Real-Time Indian Stock Market Simulator in Python — Here's How 📊

Krishna Jha — Tue, 16 Jun 2026 10:59:15 +0000

You know that feeling when you want to learn stock trading but don't want to risk actual money? Or when you want to test a trading strategy without losing your savings? That's exactly what inspired me to build NSE Live Terminal—a full-featured paper trading simulator for Indian stocks, and I'm making it open-source for everyone.

What is NSE Live Terminal?

NSE Live Terminal is a real-time stock market simulation dashboard where you can:

🛒 Execute market buy/sell orders on 12 major Indian stocks
📊 Watch live intraday charts powered by Plotly
💼 Track your portfolio with real-time P&L calculations
🏆 Compete on a live leaderboard with other traders
⚡ Get data refreshed every 15 seconds automatically

The best part? You start with ₹1 Crore (10 million rupees) in virtual cash—plenty to experiment!

Why I Built This

Paper trading is criminally underrated. Most people dive into real stock trading without practicing first. But there's a disconnect:

Traditional paper trading apps are boring or behind paywalls
You don't get real-time data for Indian stocks
Building your own means you actually understand how markets work

So I decided to build one that's modern, interactive, and free.

The Tech Stack (It's Simpler Than You Think)

Frontend: Streamlit (Python UI framework)
Database: SQLite3 (Local file-based DB)
Data Source: Yahoo Finance (yfinance SDK)
Charting: Plotly
Deployment: Railway (Docker containerized)

Why these choices?

Streamlit: Zero frontend knowledge required. Deploy in 5 minutes.
SQLite: No backend server. Perfect for projects that don't need scaling.
yfinance: Free real-time stock data for NSE instruments.
Plotly: Beautiful, responsive charts with minimal code.
Railway: Dead simple Docker deployment with a free tier.

Core Features Breakdown

1️⃣ Authentication (Clean & Simple)

# User enters nickname + 4-digit PIN
# Auto-creates account on first login
# All data stored locally in SQLite

No email verification nonsense. Just pick a username and PIN. Instant access.

2️⃣ Live Trading Engine

# Real-time price from yfinance
# Buy/Sell execution with balance validation
# Auto-calculates average buy price
# Instant P&L computation

When you buy stocks, the app automatically calculates your average cost basis. When you sell, it updates your portfolio and shows you profit/loss instantly.

3️⃣ The 12-Stock Universe

We track these major Indian blue-chips:

Tech: TCS, Infosys
Banking: HDFC Bank, ICICI Bank, SBI
Energy/Infra: Reliance Industries, Adani Ports, NTPC
Auto: Maruti Suzuki, M&M
Consumer: ITC, Hindustan Unilever

Why just 12? Focus > chaos. These are the most liquid, most traded stocks on NSE—perfect for learning.

4️⃣ Real-Time Charts

# 5-minute interval data over last 5 days
# Plotly automatically crops to tight boundaries
# No flat lines, no empty space
# Updates every 15 seconds

The charts use tight autoscaling so you actually see the volatility. No boring flat lines that waste screen space.

5️⃣ Portfolio Dashboard

Quantity held
Average buy price (weighted)
Current market price
Current value
Unrealized P&L (green if profit, red if loss)

At a glance, you know exactly how your portfolio is doing.

6️⃣ Live Leaderboard

# Net Worth = Cash + Value of Stock Holdings
# Rankings update in real-time
# Compete with friends / colleagues

Everyone starts with ₹1 Crore. Who can grow it the most? Create a friendly competition!

Getting Started (3 Steps)

Step 1: Clone & Install

git clone https://github.com/kosmoscpp/paper-trading.git
cd paper-trading
pip install -r requirements.txt

Step 2: Run Locally

streamlit run app.py

Visit http://localhost:8501 and start trading.

Step 3: Deploy (Optional)

Want to share it with friends? Deploy to Railway in 2 minutes:

Push your repo to GitHub
Connect Railway to your GitHub account
Add Dockerfile config
Deploy

(Or use my live version: https://paper-trader-kosmos.up.railway.app/)

Under the Hood: How It Works

Database Schema

-- Users table
CREATE TABLE users (
    username TEXT PRIMARY KEY,
    pin TEXT,
    balance REAL
);

-- Portfolio table
CREATE TABLE portfolio (
    username TEXT,
    ticker TEXT,
    quantity INTEGER,
    avg_price REAL,
    PRIMARY KEY (username, ticker)
);

Super simple. Two tables. That's it.

The Trading Engine

# When you BUY:
1. Validate you have enough cash
2. Deduct from balance
3. Add to portfolio (or update if you already own it)
4. Recalculate weighted average price

# When you SELL:
1. Check if you own enough shares
2. Add cash back to balance
3. Reduce quantity in portfolio
4. P&L is calculated on the fly

Background Data Sync

# Every 15 seconds:
while True:
    for each_stock in STOCK_DICT:
        fetch_live_price_from_yfinance()
        cache_in_session_memory()
    sleep(15)

This background loop keeps your charts fresh without hammering Yahoo Finance's API.

What I Learned Building This

Streamlit is ridiculously fast for MVPs. Went from zero to deployed in a weekend.
SQLite scales further than you think. For paper trading with 50+ users? Totally fine.
Real-time charting matters. When charts update live, trading feels real. Psychological engagement is everything.
Cache strategically. Don't hit the API every second. Cache + periodic refresh is the sweet spot.
UX > Features. A clean authentication screen and readable tables beat 50 features nobody uses.

Next Steps / Roadmap

📈 Advanced charts: Candlestick patterns, technical indicators (RSI, MACD)
🏅 Achievements: Badges for milestones (first 1M profit, etc.)
💬 Social features: Comment on trades, share portfolio
📱 Mobile app: React Native wrapper
🤖 Strategy backtester: Upload your strategy, backtest it historically

The Bigger Picture

This project isn't just about paper trading. It's about making financial literacy accessible. Stock market knowledge shouldn't be behind paywalls or require intimidating setup.

With an open-source simulator:

Students learn how markets actually work
Traders practice strategies risk-free
Developers see a real full-stack example
Communities (like Indian Dev communities) get a shared learning tool

Try It

Live App: https://paper-trader-kosmos.up.railway.app/
GitHub: https://github.com/kosmoscpp/paper-trading
(Might be down now!)

No signup. No BS. Just pick a username, set a PIN, and start trading with ₹1 Crore.

Have feedback? Found a bug? PRs welcome! This is open-source—contributions make it better for everyone.

Questions?

How do you build a Streamlit app? Check the app.py—it's heavily commented
How does the database work? Two simple tables—look at the schema
How do you deploy? Docker config is included
Why this stack? See my "Tech Stack" section above

Drop a comment below or open an issue on GitHub. Let's build this together! 🚀

Happy trading, and may your P&L be green! 📈