This study group is about the internals of compilers, programming languages, distributed systems, databases, file formats, internet protocols, operating systems, browsers, emulators, and to build a community around this kind of exploration. You're not expected to have attended previous weeks and expected to adhere to the standards of the Geneva War Convention (optional).

Since we're just starting out, we plan on meeting once a month on a random Sunday afternoon that will be decided in the WhatsApp/Discord GC and work on the planned topics listed here. Feel free to join us during these sessions and decide if this group suits you!

OFFICIAL FIRST SESSION ! by vxsha-256

• Zig Internals + Linux Kernel Module Programming
  Zig is a self-hosted, low-level systems programming language which is just a joy to use. We'll be going over the internals of the language and developing a Linux kernel module on a x86-64 cloud VM.

• Simple Git-Server on EC2 by Ritesh Koushik

• vxsha-256

  • Upcoming:
    • Personal-Devlopment-Environment: Personalizing Omakub by DHH
    • Theory-Showase: The Engineering behind Regex & Email
    • Data-Structure-Internals: Hash Table
    • Book-review: Designing Data-Intensive Application
    • Paper-Review: Raft Protocol

• vxsha-256

  • Upcoming:
    • Disk-based Log-Structured Hash Table Store in Go
    • Network programming in C x Berkeley Sockets API
    • Tiny deep learning compiler written in C++
    • Multi-threaded proxy Server in Zig

Pre-Season 01: April 7th, 2024

• CHIP-8 Emulator by Aadithyaa
• Recreating Pong on Bare-Metal by Aadithyaa
• Implementing x86 BootLoader by Praneeth

September 2024 - December 2024

✦ Reviewing DOOM:

Explore DOOM 3 Source Code and its engineering, such as the Quake III arena engine, Binary Space Partitioning, Fast inverse square root algorithm, Lectures from John Carmack & more.

✦ PL & The Web:

The 1 Billion Row Challenge, Exploring Programming Language Runtimes, Crash Course into Low-Latency Systems and Large-Scale Backend Engineering.

✦ Interpreters, Package managers, and Planetary databases:

Go over the Crafting Interpreters Book, Dive into Reproducible builds with Nix, and review Monarch: Google’s planet-scale in-memory Time Series Database.

✦ Networking guide to the Internet:

Intro to Networking fundamentals, Practical end-to-end Authenticated Encryption, Speedrunning computer networking, and Reading Post-Mortems of Catastrophic Failure in Big Tech Companies.

✦ ML systems & Advanced Hardware (Semiconductors + GPU):

Internals of JAX, ML systems and Compilers, SOTA papers such as Q*, and KANs, a short look into the advancements in semiconductors and computer graphics (via conferences, video game company-specific blog posts, etc).

BSOD is a one-week intense jam where you implement a cool piece of software from scratch. Writing something from scratch turns theory into practice. You may think you know how a piece of technology works, but until you write it yourself, you truly wouldn't understand it completely.

1. ZigFest: 8-day crash course into Zig and Systems Engineering by vxsha-256

   Designing SIMD Algorithm from Scratch, Building your own TCP/IP, Modern SOTA in-memory cache implementation, and Rebuilding Redis from the ground up.

2. Deployment from Scratch: over-engineering a website as of 2024 by vxsha-256

   Learn how how web-apps work in production by working on our very own website - ASRG.tech! Learn the fundamentals for setting up servers and provisioning databases while gaining real-life experience.

3. OS-Dev: 4-week speedrun of building a mini-os from scratch with Rust and C by vxsha-256

   Implementing a kernel from scratch, exploring the C run-time model, concurrency and hypervisors, and much more hell has to offer !

4. UNIX Jam: 1-week festival of intense systems programming and high-performance optimizations by vxsha-256

   Deep look into io_uring and eBPF, recreate coreutils with your favorite language, distributed system challenges, writing x86 assembly for FFMPEG and so much more fun stuff.

5. Compiler Construction: 10-day jam of building modern compilers by vxsha-256

   SOTA compiler optimization techniques, design experimental features, work on your own virtual machine around it, learn from other more established compilers.

A week-long hacking retreat to work on a variety of OCaml projects, including but not limited to the compiler, concurrency libraries, platform tooling, and benchmarking. Dive into functional programming and learn to appreciate actual ML languages instead of drooling over a whitepaper like Haskell.

Free-for-all kind of event where people give talks, get help on their homework/projects and work on random stuff. This is open to all and is an excellent way to integrate into the community. You can even just sit and watch what each member is doing without necessarily needing to pair-program.

Ritesh Koushik

 1. Build a Centralized Package Registry for Go (like npm or crates)
 2. Build your own AWS S3 

vxsha-256 (Contributors Welcome!)

    1. Watch Party: Lex Friedman Podcast Specials (Andrej Karpathy, John Carmack, et al)
    2. Reverse Engineering WannaCry using Ghidra
    3. Cloud Infrastructure from scratch (Imagine Railway) 
    4. SystemsCon - hack around popular oss projects
    5. Formal methods & SAT solvers

The only requirements you need to join the study group are pure consistency and willingness to work and have fun. This is an all-inclusive community where there are little to no barriers (aside from the ground rules). Do visit the website to learn about our underlying philosophy and please refer to the Left-Pad incident on why harshly emphasize working on projects outside your comfort zone. This group is not for you if you only wanna do the bare minimum and stay in your comfort zone.

You do not talk about ASRG. This might as well be an illegal gambling den and I might get expelled from Amrita for doing something cool. But please do share this with anyone who might be interested and save a life.

This group is meant to explore the depths of CS and is meant to be HARD. My philosophy is essentially:

The more you train in battle, the less you bleed in war.

If you wish to work in Big Tech companies handling large-scale issues, it's paramount that you know your fundamentals and there is no substitute for actual experience.

As a rule of thumb, if your project idea can be found on a majority of other's resumes - It is not a good idea. Come up with your own idea that solves an actual real-world problem or if you lack creativity, exhaust the group's resources cause there is always something for everyone here.

Kind of a nitpick but please learn to use NeoVim or Vim or Emacs or Spacemacs or Helix or any other thing. Avoid Bloated IDEs and learn your goddamn environment, It is embarrassing to see CS majors not knowing how to debug errors and getting too comfortable because everything is set up for them and abstracted away.

Just take some to learn to set stuff up, read the docs, and debug your tools - it really goes a long way. If you still prefer IDEs, we'd love to see you go blazingly fast and teach us about your favorite features (Amrita is hectic at times and we barely have 2 hours to work on the projects - it really helps if we're fast as hell).

- Contributions welcome!

1. Check if your project ideas satisfy the requirements specified in the ground rules.
2. If so, check the existing project ideas to see if your idea integrates nicely with one of them, or if it is a separate project on its own.
3. Is your project completed? then you probably want to showcase it in a session.
4. If not, is it a reading/exploration project? Then it probably doesn't require a GitHub repo, contact the lead or hit us up in the WhatsApp group.
5. If it is a group project to work on, make sure it fits nicely within 2 hrs. It probably requires a GitHub repo, contact the lead anyway or hit us up in the WhatsApp group.
6. Once a date is confirmed for your project, find reference material to get started on it, and share this with everyone else.
7. Present/read/develop the project, and have fun!

1. Refer to each project for any possible GitHub issues.
2. Feel free to reach out to the primary developer of the project from the README file.
3. Follow any code guidelines specified in the README (chances of there being any guidelines whatsoever are pretty slim).
4. If it's a large contribution with significant complexity, consider bringing it up as an idea for an open session or BSOD.