DEV Community: Muhammad Adil

SQLite as Your Default Database

Muhammad Adil — Thu, 20 Aug 2026 22:23:04 +0000

Most developers reach for PostgreSQL or MySQL before they even finish sketching the schema. That reflex adds layers of complexity: connection pools, migrations, network hops, and ops overhead. SQLite flips the script. It runs inside your process, needs zero setup, and still handles millions of rows without breaking a sweat. The catch? You have to stop treating it like a toy.

Where SQLite actually wins

Startups and solo builders ship faster with SQLite because there’s no server to babysit. No ports to open, no credentials to rotate, no backups to configure. The entire database lives in a single file. Copy it, version it, or toss it in S3, done. That simplicity extends to testing: spin up an in-memory instance, run your suite, and tear it down without leaving residue.

Performance surprises people. SQLite benchmarks faster than client-server databases for most read-heavy workloads. It avoids the network round-trip, and its query planner is shockingly good. Write contention is the only real bottleneck, but even that can be mitigated with WAL mode and batching. For 90% of apps, the bottleneck isn’t the database, it’s the ORM or the N+1 queries you wrote.

When to reach for something else

You need concurrent writes from multiple machines. SQLite locks the entire file during writes, so distributed systems will hit contention.
Your dataset exceeds 1TB or grows unpredictably. SQLite files can scale, but sharding and replication are manual work.
You rely on advanced features like row-level security, materialized views, or geospatial indexes. SQLite covers the basics well, but Postgres has a decade head start on niche extensions.
Your team already maintains a Postgres cluster. Adding another database just for one app rarely pays off.

Making SQLite production-ready

Treat the database file like code. Store it in Git alongside migrations, and automate restores from CI. Use WAL mode to allow reads during writes, and set a busy timeout so queries don’t fail under contention. For backups, copy the file while the app is running, SQLite guarantees consistency even during writes.

Connection pooling isn’t needed, but you still want to reuse connections. Open one per process and keep it alive. Libraries like better-sqlite3 for Node or sqlite3 for Python make this trivial. Avoid ORMs that hide the simplicity; raw SQL or a lightweight query builder keeps you in control.

Deploying SQLite in the cloud

Fly.io, Railway, and Render all support SQLite out of the box. They give you a persistent volume, so the file survives restarts. For serverless, use LiteFS to replicate the file across instances. It’s a bit more work, but cheaper than managed Postgres and just as reliable for read-heavy workloads.

If you’re on AWS, store the file in EFS or S3 and mount it to your container. The latency is higher, but still acceptable for apps with moderate traffic. For high availability, replicate the file to multiple regions using rsync or a service like Litestream. It’s not automatic failover, but it’s simple and battle-tested.

Schema changes without downtime

SQLite doesn’t support ALTER TABLE for everything, but you can work around it. Create a new table, copy the data, then swap the names. Tools like sqitch or alembic automate this, but writing the SQL yourself keeps the process transparent. Always test migrations on a copy of production data, SQLite’s simplicity doesn’t make it immune to human error.

The hidden cost of simplicity

SQLite’s biggest strength, being a single file, can also be a weakness. If the file corrupts, you’re restoring from backup. Enable PRAGMA integrity_check on startup, and log errors aggressively. Most corruption comes from hardware failures or sudden power loss, so run on reliable infrastructure.

Debugging is different. No slow query logs or connection metrics out of the box. You’ll need to instrument your app to track query times and errors. Libraries like opentelemetry work fine with SQLite, but you have to wire them up yourself.

Start with SQLite tomorrow

Replace your local dev database with SQLite. No more waiting for Docker to boot.
Use it for internal tools, prototypes, or side projects. If it breaks, you’ll know in minutes, not hours.
Benchmark it against your current setup. You might find the performance gap is smaller than you think.
Deploy a small feature with SQLite in production. Measure memory, latency, and ops overhead before committing.

SQLite isn’t a silver bullet, but it’s the right default for most apps. The next time you sketch a schema, ask yourself: do I really need a separate database server? Chances are, the answer is no.

This post was originally published on my site. Read the full article and more →

Linux 7.2: Key Changes and Upgrade Reasons

Muhammad Adil — Thu, 20 Aug 2026 20:27:52 +0000

Linux 7.2 was officially released in August 2026, but it packs enough under-the-hood improvements to matter for anyone running servers, containers, or even a local dev environment. If you're still on 6.x or an older 7.x release, here's what you're missing and why it might be time to upgrade.

Performance: Small Gains, Big Impact

The kernel team didn't rewrite the scheduler this time, but they did squeeze out measurable wins in specific workloads. File I/O latency dropped for NVMe drives, especially with small random reads. This won't turn a budget SSD into a high-end PCIe 5.0 drive, but it shaves off enough microseconds to notice in database queries or CI pipelines.

Memory management got attention too. Transparent Huge Pages (THP) now supports multi-size pages, allowing the kernel to mix 2MB and 1GB pages dynamically. For applications that allocate large chunks of memory but don't use it all at once, this may reduce TLB misses without the overhead of forcing everything into huge pages. Redis and PostgreSQL users may see a modest but consistent reduction in CPU usage.

Security: Not Just CVE Patches

Linux 7.2 addresses a handful of CVEs, but the more interesting changes are the proactive ones. The kernel now enforces stricter bounds checking on BPF programs, which closes a class of potential exploits before they're even discovered. If you're running Kubernetes or any other system that relies on BPF for networking or observability, this is a free security upgrade.

Another subtle but important change: the kernel now aims to make it harder for attackers to predict memory layouts by randomizing the location of its core data structures more aggressively. It's not a silver bullet, but it raises the bar for privilege escalation attacks.

Hardware Support: What's New, What's Fixed

A long-standing bug with some Realtek Wi-Fi chips has been fixed, which should improve stability for anyone using those adapters.

Networking: Quiet Improvements

The networking stack got a few quality-of-life updates.

For container users, IPv6 NAT may see efficiency improvements. If you're running Docker or Kubernetes with IPv6, you might see slightly lower latency and reduced memory usage. It's not a game-changer, but it's one less thing to worry about when scaling out.

Should You Upgrade?

If you're on Linux 6.x, the answer is almost certainly yes. The performance and security improvements alone justify the effort. For those already on 7.0 or 7.1, it depends. If you're running workloads that benefit from the I/O or memory management changes, it's worth testing. If you're just running a desktop or a simple web server, you can probably wait for the next release.

The upgrade process itself is straightforward. Most distros will handle it through their package manager. If you're compiling the kernel yourself, the config options haven't changed much, so your existing config should work with minor tweaks. Just remember to test thoroughly before deploying to production.

What's Next?

The upcoming merge window is for Linux 7.3. While no specific patches or features have been confirmed yet, you can follow the development on the Linux kernel mailing list or wait for the first release candidate.

For now, Linux 7.2 is a solid, incremental update that delivers real benefits without breaking compatibility. It's not flashy, but that's the point. The kernel team continues to refine and optimize, and that's exactly what most of us need.

This post was originally published on my site. Read the full article and more →

Mojo is Open Source: What It Means for You

Muhammad Adil — Thu, 20 Aug 2026 16:48:36 +0000

Mojo, the programming language designed to bridge Python’s ease of use with systems-level performance, just went open source. If you’ve been waiting to try it without jumping through hoops, now’s the time. But what does this change actually mean for developers?

Why Mojo Matters

Python dominates AI and data science for good reason. It’s simple, flexible, and packed with libraries. But when you need speed, Python hits a wall. Mojo fixes that by letting you write Python-like code that compiles to native machine code. No more rewriting hot loops in C++ or Rust just to get acceptable performance.

The open-source release removes the biggest barrier to adoption. Before, you needed an invite to even run Mojo code. Now, anyone can download the compiler, experiment, and contribute. For teams building performance-sensitive applications, this is a game-changer.

What You Can Do With Mojo Today

Write Python code that runs as fast as C, with zero changes to the syntax you already know.
Use Mojo’s metaprogramming features to generate optimized code at compile time, something Python can’t do.
Leverage SIMD and parallelism without leaving the language, ideal for numerical computing and AI workloads.
Integrate seamlessly with existing Python code, so you don’t have to rewrite your entire stack to get a speed boost.

Where Mojo Fits in Your Stack

Mojo isn’t here to replace Python. It’s here to handle the parts of your codebase that need to be fast. Think of it as a drop-in accelerator for performance-critical sections. You keep writing the rest of your application in Python, but when you hit a bottleneck, you rewrite just that part in Mojo.

For AI engineers, this means you can train models faster without switching languages. For full-stack developers, it means you can optimize backend services without learning a new ecosystem. The open-source release also means you can start using Mojo in production without worrying about vendor lock-in.

The Catch: It’s Still Early

Mojo is powerful, but it’s not yet a drop-in replacement for everything. The ecosystem is small compared to Python’s. You won’t find as many libraries or as much documentation. If you’re building something that relies on niche Python packages, you might need to write your own Mojo bindings or wait for the community to catch up.

The tooling is also a work in progress. Debugging Mojo code isn’t as smooth as debugging Python, and IDE support is limited. But with the source now available, these gaps will close faster. If you’re willing to tolerate some rough edges, the performance gains are worth it.

How to Get Started

Clone the Mojo repository from GitHub and follow the build instructions. The process is straightforward if you’re familiar with compiling languages from source.
Run the examples to see how Mojo handles tasks like matrix multiplication or parallel loops. Pay attention to the performance numbers.
Try rewriting a slow Python function in Mojo. Start with something simple, like a numerical loop, and compare the speed.
Join the Mojo community on Discord or GitHub. The core team is active, and early adopters are sharing tips and tricks.

Should You Switch?

If you’re happy with Python and don’t need more speed, there’s no rush. But if you’re working on AI, high-performance computing, or any project where Python’s slowness is holding you back, Mojo is worth a look. The open-source release means you can experiment without risk.

For most developers, the best approach is to use Mojo where it makes sense and stick with Python for everything else. Over time, as the ecosystem grows, you might find yourself reaching for Mojo more often. But for now, it’s a tool for specific problems, not a wholesale replacement.

Mojo’s open-source debut is a big deal. It gives developers a new way to write fast, maintainable code without leaving Python’s comfort zone. The next step is yours: download it, try it, and see if it solves a problem you care about.

This post was originally published on my site. Read the full article and more →

Drone deliveries take off, noise and all

Muhammad Adil — Thu, 20 Aug 2026 16:47:23 +0000

The next time you order a pack of batteries or a phone charger, it might arrive by air instead of a delivery truck. Amazon, Walmart, and even DoorDash are betting big on drones to shrink delivery times to under an hour. But as these networks grow, so do the headaches for the people living underneath their flight paths.

The expansion race

Amazon just announced plans to bring its Prime Air service to nearly 500 U.S. cities by the end of 2026, up from just 10 today. The latest rollouts include Chicago, Cleveland, and Atlanta, with each hub covering about 175 square miles. Walmart isn’t far behind, partnering with Wing and Zipline to hit 1 million deliveries already and aiming for 270 stores by 2027. Uber’s collaboration with Zipline targets a staggering 1 million daily deliveries by 2029.

For now, drones handle small, lightweight packages, think shoebox-sized items under five pounds. That limits their usefulness, but it’s enough to cover a surprising chunk of online orders. The bigger hurdle isn’t payload, though. It’s the weather. Wind, rain, and extreme temperatures can ground entire fleets, turning a 30-minute promise into a delayed delivery.

Safety records aren’t spotless

Zipline leads the pack with over 100 million miles flown and a backup parachute system that’s already saved a few errant drones. Amazon’s track record is rockier. In 2025 alone, its drones crashed into a construction crane in Arizona, took down an internet cable in Texas, and collided with an apartment building in Richardson. The FAA and NTSB are still investigating some of these incidents.

We trained our algorithms, we felt pretty good, but in the real world the performance just wasn’t good enough. That was a humbling experience.

Wing hasn’t escaped unscathed either. A drone caught fire after landing on power lines in Australia, cutting electricity to 2,000 people. Another crashed and burned in Texas earlier this year. These aren’t dealbreakers for regulators yet, but they’re a reminder that autonomous flight isn’t foolproof.

The sound of progress

Safety might grab headlines, but noise is the real sticking point for communities. Residents describe the drones as flying leaf blowers or lawnmowers hovering 20 feet overhead, sometimes dozens of times a day. Dogs bark, conversations pause, and patience wears thin.

A Michigan resident counted six flyovers in 90 minutes, comparing the noise to a small helicopter.
In Texas, drones outnumbered street traffic, altering the ambiance of homes with no opt-out option.
Privacy concerns surfaced when drones repeatedly passed over backyards, making people feel watched.

Amazon insists its drones only use cameras for navigation, not surveillance, and that no human monitors the feed. But try telling that to someone who’s had four drones buzz their backyard while sunbathing. Some residents have filed FAA complaints or asked Amazon to reroute flights, with mixed results. A protest in Richardson this June suggests patience is running out.

What’s next

The FAA’s drone noise complaints are still low compared to helicopters or planes, but that could change as operations scale. Local governments may step in if the backlash grows, forcing companies to tweak flight paths or adjust schedules. For now, the expansion continues, with drones becoming a more common sight, and sound, in American skies.

The trade-off is clear: faster deliveries for some, constant noise for others. Whether that’s a fair exchange depends on who you ask, and where they live.

This post was originally published on my site. Read the full article and more →

Why Google Stopped Git Tags for Android Code

Muhammad Adil — Thu, 20 Aug 2026 15:54:50 +0000

If you’ve pulled Android source code recently, you might have noticed something missing. Git tags for certain repositories stopped updating. This isn’t a bug, it’s a deliberate change from Google. The shift affects how developers track releases, sync code, and manage dependencies. Here’s what’s happening under the hood.

What changed with Android Git tags

Google historically used Git tags to mark stable points in the Android Open Source Project. These tags, like android-14.0.0_r1, let developers fetch exact release versions. Now, some repositories, especially newer ones, no longer receive these tags. Instead, Google is pushing updates directly to branches like android14-release without tagging them.

The move aligns with how Google manages internal development. Tags were always a convenience for external contributors, not a core part of their workflow. By dropping them, Google reduces maintenance overhead while still providing access to the latest code. The trade-off is less clarity for those relying on tagged releases.

Which repositories are affected

Newer platform repositories added after Android 12.
Vendor-specific codebases like Pixel device trees.
Kernel and driver repos that sync with upstream Linux.
Experimental or preview branches that never had tags.

Core AOSP repositories, such as frameworks/base or system/core, still receive tags. But if you’re working with device-specific code or newer modules, you’ll need to adjust. The change is most noticeable in projects where Google doesn’t prioritize external compatibility.

How this impacts your workflow

Without tags, syncing to a known stable version becomes harder. You can no longer run repo init -b android-14.0.0_r1 and expect a predictable snapshot. Instead, you’re left with two options: track a moving branch or manually pin commits.

Use repo sync -c to fetch only the current branch, reducing bandwidth.
Check out specific commits using git checkout if you need stability.
Monitor Google’s release notes for commit hashes tied to specific builds.

Why Google made this change

Tags add friction to Google’s internal development. Every tag requires a signed commit, which slows down rapid iteration. Since most AOSP contributors are Google engineers, the company optimized for their workflow. External developers are now expected to adapt.

There’s also a security angle. Tags can be spoofed or misused to distribute unofficial builds. By relying on branches, Google maintains tighter control over what gets labeled as a release. This reduces the risk of malicious forks masquerading as official versions.

What to do instead of relying on tags

If you need reproducible builds, start tracking commit hashes. Google’s release documentation often includes the exact commit for a given version. For example, the Android 14 QPR1 release notes list the top-of-tree commit for each repository.

For CI/CD pipelines, replace tag-based syncs with branch-based ones. Use repo init -b android14-release and repo sync -c to stay on the latest. If you need a specific point in time, check out the commit hash from Google’s release notes.

The future of Android versioning

This change isn’t temporary. Google is moving toward a model where branches are the primary way to track releases. Tags will likely remain only for major platform releases, like android-15.0.0_r1. Everything else will rely on branches or commit hashes.

For developers, this means more manual work. You’ll need to document commit hashes for your builds and update them as new releases roll out. The upside is that you’re no longer tied to Google’s tagging schedule, you can pull the latest code whenever you need it.

If you’re building for production, always pin to a commit hash. Branches move fast, and you don’t want your app to break because of an unexpected update.

Final takeaways

Google’s shift away from Git tags is a reality for Android developers. While it complicates version tracking, it also reflects how the company actually develops the OS. The key is to adapt: use branches for flexibility, commit hashes for stability, and Google’s release notes as your guide. The days of simple tag-based syncs are over, time to embrace the new workflow.

This post was originally published on my site. Read the full article and more →

What's New in Go 1.27: A Developer's Practical Guide

Muhammad Adil — Thu, 20 Aug 2026 00:17:27 +0000

Go 1.27 landed in August 2026, and while it doesn’t introduce earth-shattering changes, it polishes the language in ways that add up. If you’re maintaining production services or building new ones, these updates can save you time and headaches. Let’s cut through the noise and focus on what actually affects your code.

Performance: Faster Without Changing a Line

The compiler and runtime received several under-the-hood optimizations. Benchmarks show a 3-5% speedup in typical server workloads, with some microbenchmarks hitting 10%. This isn’t magic, it’s the result of better inlining decisions and reduced memory allocation overhead. The best part? You get this for free. Just recompile your existing code with Go 1.27 and measure the difference.

One standout improvement is in garbage collection. The GC now handles large heaps more efficiently, which matters if you’re running services with hundreds of gigabytes of live data. Latency spikes during GC cycles should be less pronounced, though you’ll still want to monitor this in production.

Language Tweaks: Small but Useful

Go 1.27 introduces a few language changes that simplify common patterns. The most notable is the addition of the new built-in function clear. It works on slices, maps, and type parameters, letting you reset collections without reallocating them. This is particularly handy for pooling or reusing buffers.

For slices, clear sets all elements to their zero value and truncates the slice to length zero.
For maps, it removes all entries, leaving the map empty but with the same capacity.
For type parameters, it behaves based on the underlying type, useful for generic code.

Another small but welcome change is the ability to use //go:linkname with methods. This was previously restricted to functions, which made certain low-level optimizations awkward. Now you can link methods directly, which is useful for writing highly optimized libraries or interfacing with C code.

Tooling: Better Debugging and Dependency Management

The go command got smarter in a few ways. First, go mod tidy now preserves // indirect comments in your go.mod file. This might seem minor, but it reduces noise in diffs when you’re managing dependencies across large teams. The tool also does a better job of detecting and removing unused dependencies, which keeps your builds lean.

Debugging gets a boost with improved DWARF information. If you’ve ever struggled to inspect variables in a debugger, you’ll notice the difference. The Go team worked with the Delve team to ensure that common debugging scenarios, like stepping through inlined functions, are more reliable. This is especially useful when debugging optimized builds.

Standard Library Additions: Filling the Gaps

The standard library now includes math/rand/v2, a new package that provides faster and more secure random number generation. The old math/rand package remains for backward compatibility, but v2 is where you should look for new code. It uses a faster algorithm and defaults to a cryptographically secure seed, which is a nice improvement over the old behavior.

Another useful addition is slices.Concat, which concatenates multiple slices into one. This is a small quality-of-life improvement, but it’s the kind of thing that reduces boilerplate in everyday code. The function is variadic, so you can pass as many slices as you need.

Upgrading: What to Watch For

Upgrading to Go 1.27 is straightforward, but there are a few things to keep in mind. The language changes are backward-compatible, so your existing code should compile without issues. However, if you’re using //go:linkname with methods, you’ll need to update those directives to match the new syntax.

Run go test ./... after upgrading to catch any unexpected behavior.
Check your CI pipelines to ensure they’re using the correct Go version.
If you’re using cgo, verify that your build flags still work as expected.

Should You Upgrade?

If you’re already on Go 1.22 or later, the answer is almost certainly yes. The performance improvements alone make it worth the effort, and the tooling and language tweaks are icing on the cake. For teams on older versions, this is a good opportunity to catch up. The Go team has a strong track record of backward compatibility, so you’re unlikely to run into major issues.

That said, if you’re in the middle of a critical release cycle, it might make sense to wait until things stabilize. But for most projects, the benefits outweigh the risks. Start with a non-production environment, run your benchmarks, and measure the impact before rolling it out widely.

Go 1.27 isn’t a revolutionary release, but it’s a solid step forward. The performance gains, tooling improvements, and small language additions all add up to a better developer experience. If you’re serious about Go, this is a version worth adopting.

This post was originally published on my site. Read the full article and more →

How Claude Code Really Remembers Your Work

Muhammad Adil — Wed, 19 Aug 2026 23:49:52 +0000

I once deleted over a hundred old Claude Code sessions, freeing up hundreds of megabytes. A few days later, a brand-new chat referenced a bug ID from one of those deleted conversations. That moment made me question how Claude actually remembers things. The answer turned out to be simpler than I expected, but it required rethinking how sessions, memory, and context work together.

Saved sessions are just files on disk

Every conversation in Claude Code gets stored as a JSON Lines file, with each line representing a message, response, or tool call. These files live in a project directory, organized by UUID. When you have 111 saved sessions, you’re looking at 111 of these files, plus any associated data like attachments or tool artifacts.

These files exist so you can resume old conversations later. The /resume command lists them, and selecting one reconstructs the chat from the saved transcript. But here’s the key detail: starting a new session doesn’t automatically load all those old files. They’re more like folders in a filing cabinet, available if you need them, but not dumped onto your desk by default.

Memory and context are not the same as sessions

When I deleted those 111 sessions, I removed the transcripts but not the distilled knowledge Claude had extracted from them. That knowledge lives in memory files like MEMORY.md, which store key facts, decisions, and preferences from past work. A 40,000-word conversation about a production outage might be compressed into a single line: "Authentication failure caused by missing database migration."

This explains why a new session could still reference DEF-2210. The bug ID wasn’t pulled from an old transcript, it was already saved in memory. Deleting transcripts and deleting memory are two separate operations. I chose to keep the memory, which is why the knowledge persisted.

Project files and hooks add more persistent knowledge

Memory files aren’t the only source of persistent knowledge. Claude Code also reads project files like CLAUDE.md, which act like an instruction manual for the AI. These files can define rules, preferences, or context that apply to every session, regardless of whether old transcripts exist. Deleting all past conversations won’t remove these instructions, they’re part of the project setup.

Hooks add another layer. A SessionStart hook runs automatically when a new session begins, injecting additional context or instructions. This means even a fresh conversation can start with a preloaded set of facts or guidelines, all without referencing old transcripts.

What actually gets loaded in a new session

The active context is the information Claude uses to generate responses in the moment. It’s a bundle of the current conversation, memory files, project instructions, and any data injected by hooks. This context is rebuilt every time you start a new session, but it doesn’t include old transcripts unless you explicitly resume them.

Old session transcripts remain on disk but aren’t loaded by default.
Memory files store distilled knowledge from past work.
Project files like CLAUDE.md provide persistent instructions.
Hooks can inject additional context at session start.
The active context combines all these elements for the current conversation.

How to manage session history without losing knowledge

My cleanup deleted the old transcripts but preserved the memory directory. This was intentional, I wanted to free up space without erasing the project’s knowledge. A careless deletion could have removed both, which is why it’s important to understand what each operation affects.

To prevent future buildup, I set a retention policy that automatically prunes sessions older than seven days. This keeps the /resume list manageable without touching memory files or project instructions. The policy only affects saved transcripts, not the persistent knowledge that makes Claude useful across sessions.

The three-layer model to remember

The simplest way to think about Claude Code’s memory system is in three layers. The bottom layer is saved session transcripts, the files you can resume later. The middle layer is persistent knowledge, including memory files, project instructions, and hooks. The top layer is the active context, which is rebuilt for each new session based on the middle layer.

When you delete old sessions, you’re only cleaning up the bottom layer. The middle layer remains intact, which is why Claude can still reference past work in new conversations. Understanding this distinction helps you manage your project’s history without accidentally losing what makes the AI effective.

Next time you see Claude reference something from an old conversation, remember: it’s not reading your deleted transcripts. It’s pulling from the persistent knowledge you chose to keep.

This post was originally published on my site. Read the full article and more →

Why λλ is the Language Silicon Photonics Engineers Have Been Waiting For

Muhammad Adil — Wed, 19 Aug 2026 20:29:38 +0000

Silicon photonics promises faster, more efficient chips by replacing electrons with photons. The problem is, designing these circuits feels like building a skyscraper with Lego. You spend more time wrestling with simulation tools and manual netlists than actually innovating. λλ (pronounced 'lambda lambda') fixes that. It's a domain-specific language built from the ground up for optical hardware, not an afterthought bolted onto existing EDA tools.

What Makes Silicon Photonics Different

Electrical circuits deal with voltages and currents. Optical circuits deal with wavelengths, phases, and polarization. The abstractions that work for Verilog or VHDL fall apart when you try to model a ring resonator or a directional coupler. λλ gives you first-class constructs for these optical primitives. You describe the behavior you want, and the compiler figures out how to map it to physical components.

A Language That Speaks Hardware

Most languages treat hardware as an afterthought. λλ flips that. It starts with the constraints of silicon photonics: fabrication tolerances, waveguide losses, thermal sensitivity. The type system enforces physical rules. For example, you can't accidentally connect two waveguides with mismatched widths. The compiler catches it before you waste a tape-out.

Waveguides are typed by their dimensions and material properties.
Components like splitters and filters expose their insertion loss in the type signature.
Thermal tuning parameters are part of the component definition, not an external script.
Layout-aware compilation prevents impossible routing early in the design process.

Simulation Without the Headache

Traditional tools force you to export your design to a separate simulator, then manually tweak parameters in a GUI. λλ integrates simulation directly into the language. You write testbenches in the same syntax as your design, and the compiler generates the simulation netlist. Need to sweep a parameter? Just write a loop. The results feed back into the same environment, so you can iterate without context-switching.

This tight loop changes how you work. Instead of waiting hours for a simulation to finish, you get feedback in seconds. That means more experiments, fewer assumptions, and designs that actually work the first time.

From Code to Fabrication

The end goal is a chip, not a pretty schematic. λλ compiles to GDSII, the standard format for fabrication. But it doesn't stop there. The compiler also generates the test structures and calibration routines you'll need to verify the chip. It even includes annotations for the foundry, so you don't have to manually fill out design rule check forms.

Automatic insertion of alignment markers and test waveguides.
Foundry-specific design rule checks baked into the compiler.
Version-controlled layouts with diff tools for GDSII files.
Direct integration with mask preparation tools like KLayout.

Who λλ is For

If you're an electrical engineer trying to design optical interconnects, λλ will save you months of frustration. If you're a photonics researcher, it lets you focus on the physics instead of the toolchain. And if you're building the next generation of optical computers, it's the only language that scales with your ambition.

It's not for everyone. If you're happy with your current workflow, λλ won't convince you. But if you've ever thrown your hands up in despair at a SPICE netlist, it's worth a look.

Getting Started

λλ is open source and available on GitHub. The documentation includes a tutorial that walks you through designing a simple wavelength-division multiplexer. There's also a growing library of pre-built components, so you don't have to start from scratch. The community is small but active, with regular updates and a responsive team.

Silicon photonics is still in its early days. The tools we use today will shape the industry for decades. λλ isn't just another language. It's a bet on a future where optical design is as intuitive as writing software. That future starts now.

This post was originally published on my site. Read the full article and more →

Finding a Random Island with Geometry and CUDA

Muhammad Adil — Wed, 19 Aug 2026 18:38:52 +0000

You have a dataset of every coastline on the planet. You also have a random point somewhere in the ocean. The question is simple: which island is closest to that point? The answer isn't just about distance. You need to account for Earth's curvature, handle millions of coastline segments efficiently, and do it fast enough that the result feels instant. That's where geometry and CUDA come in.

Why the obvious approach fails

Most people start with the Haversine formula. It calculates the great-circle distance between two points on a sphere. For a single pair of coordinates, it's perfect. But when you scale it to millions of coastline segments, the math becomes a bottleneck. A CPU can handle a few thousand checks per second. That's not enough when you're dealing with global datasets.

The real problem isn't just the distance calculation. It's the sheer volume of comparisons. Every coastline segment is a potential candidate. Filtering them efficiently requires more than brute force. You need spatial indexing and parallel processing.

Breaking down the geometry

Earth isn't flat, so Euclidean distance won't work. The Haversine formula gives you the shortest path between two points along the surface of a sphere. Here's what you actually need to compute.

Convert latitude and longitude to radians for both the random point and each coastline vertex.
Calculate the central angle between the points using the difference in longitude and latitude.
Apply the Haversine formula to get the distance in meters or kilometers.
Repeat for every vertex in the coastline dataset and keep track of the smallest distance.

The formula itself is straightforward. The challenge is doing it millions of times without your program grinding to a halt. That's where CUDA shines.

Setting up the CUDA kernel

A CUDA kernel lets you run the same function across thousands of threads simultaneously. Each thread can process a different coastline segment. Here's how to structure it.

Load the coastline dataset into GPU memory. This includes all vertices and their coordinates.
Pass the random point's coordinates to the kernel as a constant.
Launch a thread for each coastline vertex. Each thread computes the distance to the random point.
Use shared memory to track the closest vertex across all threads. Atomic operations prevent race conditions.
Copy the result back to the CPU once all threads finish.

The key is minimizing memory transfers. Moving data between the CPU and GPU is slow. Keep the coastline dataset on the GPU and only transfer the final result back.

Optimizing for speed

Raw power isn't enough. You need to optimize the kernel to avoid wasted cycles. Here's what matters most.

Use single-precision floating-point math. Double precision is overkill for geospatial distances and slows down the GPU.
Coalesce memory access. Threads should read adjacent memory locations to maximize bandwidth.
Avoid branching. If statements inside the kernel force threads to diverge, reducing parallelism.
Use texture memory for the coastline dataset. It's cached and optimized for spatial locality.

A well-optimized kernel can process millions of coastline vertices in milliseconds. That's the difference between a sluggish application and one that feels responsive.

Handling edge cases

Not all coastline segments are equal. Some islands are tiny. Others span thousands of kilometers. You need to account for these variations.

Skip segments that are too far from the random point. A quick bounding-box check can eliminate most candidates early.
For large islands, use the centroid instead of individual vertices. This reduces the number of comparisons without losing accuracy.
Handle wrap-around at the antimeridian. Points near the International Date Line can cause distance calculations to break if not handled properly.

Putting it all together

Here's the workflow from start to finish. Load the coastline dataset. Pick a random point. Let the GPU do the heavy lifting. Retrieve the closest island.

The result isn't just a distance. It's the name of the island, its coordinates, and the exact segment that's closest. This approach scales to any dataset, whether you're working with a few hundred islands or every coastline on Earth.

When to use this approach

This method isn't just for random points. It's useful anytime you need to find the nearest geographic feature. Think of applications like real-time vessel tracking, flight path optimization, or even game development where the world is procedurally generated.

The combination of spherical geometry and GPU acceleration makes it possible to solve problems that would be impractical on a CPU alone. That's the power of thinking beyond the obvious solution.

Next time you're staring at a map and wondering which island is closest to a random spot in the ocean, remember: the answer is just a few lines of CUDA away.

This post was originally published on my site. Read the full article and more →

How I Automate Instagram on Android (adb and Rooted Devices)

Muhammad Adil — Wed, 19 Aug 2026 18:37:22 +0000

Automating your own Instagram workflow on Android, scheduling posts, exporting your data, running UI tests, comes down to two methods. Both are worth knowing, because they trade speed for reliability in opposite directions.

The two ways to automate Instagram on Android

adb tap and type: drive the app through its own screens, exactly as a person would
Rooted dump-UI and files: read the UI tree and the app's own files directly, skipping the screen where possible

The adb method

No root needed. You open Instagram with am start, dump the UI to find the button you want (New post, Share, the caption field), tap its real coordinates, and type with input text. It works on any device, but it is slower and more sensitive to layout changes, so every step verifies the screen before acting.

The rooted method (faster)

On a rooted phone you can pull a fresh UI dump the instant a screen loads and, better, read and write the app's own files. That means less waiting on animations and fewer taps that can miss. For anything data-heavy, exporting, backing up, batch work, the rooted approach is simply more reliable than steering the UI one tap at a time.

Doing it responsibly

Automation of a platform you do not control has limits. Keep it to your own account and your own legitimate workflow, respect Instagram's terms, add human-like pacing, and never use it to spam or mass-act. Used this way it is a time saver, not a bot farm, and it stays within what the platform tolerates.

Want a specific Android or Instagram workflow automated end to end? That is exactly what I do, see Android automation.

This post was originally published on my site. Read the full article and more →

OpenAI’s Cash Crunch: Why the $7 Billion Share Buyback Reveals a Deeper Problem

Muhammad Adil — Wed, 19 Aug 2026 18:10:22 +0000

OpenAI’s mission is to build artificial general intelligence safely. That goal demands massive computing power, top-tier talent, and a steady stream of cash. But beneath the hype of ChatGPT’s success lies a growing financial strain. The company’s latest move, a $7 billion share buyback, hints at a much larger issue. It’s not just about keeping employees happy. It’s about keeping the lights on.

The Illusion of a Normal Startup Move

Secondary share sales are common in Silicon Valley. Employees who joined early want to cash out some of their equity. Investors want liquidity. Companies use these transactions to reward loyalty and attract new talent. On paper, OpenAI’s $7 billion repurchase fits the mold. In reality, it’s a sign of desperation.

The scale of the buyback is staggering. Most startups conduct secondary sales in the tens or hundreds of millions, not billions. OpenAI’s valuation, now reportedly $852 billion, makes this transaction even more precarious. The company is essentially betting that future profits will justify today’s spending. But with no clear path to profitability, that bet looks increasingly risky.

The Cost of Chasing AGI

Training large language models doesn’t come cheap. OpenAI’s infrastructure costs run into the billions annually. The company also pays top dollar to retain AI researchers and engineers, many of whom command salaries well into the seven figures. Then there’s the customer acquisition side. Enterprises are adopting AI tools, but not at a pace that offsets the burn rate.

The problem isn’t just the money going out. It’s the uncertainty around when, or if, it will ever come back. OpenAI’s revenue growth is impressive, but so are its expenses. Unlike traditional software companies, AI firms can’t rely on economies of scale. Each new model iteration demands more data, more compute, and more capital. The cycle never ends.

Wall Street’s Growing Skepticism

OpenAI’s latest financial maneuver isn’t just about employees and investors. It’s a message to Wall Street. The company is preparing for a potential IPO, and it needs to convince public markets that its business model is viable. But skepticism is already mounting.

Public investors are wary of companies with no clear path to profitability, especially in unproven markets like AGI.
OpenAI’s valuation is based on future potential, not current earnings. That’s a tough sell when growth is fueled by massive spending.
Competitors like Google and Meta are pouring billions into their own AI efforts, increasing the pressure on OpenAI to keep up.
Regulatory scrutiny is intensifying, adding another layer of risk to an already volatile business model.

The Employee Retention Gamble

OpenAI’s share buyback isn’t just about liquidity. It’s a retention strategy. The company knows that its most valuable asset isn’t its technology, it’s the people building it. AI researchers have options. If they don’t see a clear path to financial reward, they’ll leave.

But this strategy has a downside. By offering early liquidity, OpenAI is signaling that it may not be around for the long haul. Employees who cash out now might not stick around for the next funding round. That could create a talent exodus at the worst possible time.

What Happens Next

OpenAI’s $7 billion problem isn’t going away. The company has three options, none of them ideal. It can keep raising capital at higher valuations, hoping that revenue growth will eventually catch up. It can pivot to a more sustainable business model, though that risks slowing down its AGI ambitions. Or it can accept that its current trajectory is unsustainable and make drastic cuts.

The most likely outcome is a mix of all three. OpenAI will keep raising money, but at a slower pace. It will try to monetize its existing products more aggressively. And it will make tough decisions about where to allocate resources. The question is whether those moves will be enough to keep the company afloat.

The AI race isn’t just about who builds the best model. It’s about who can survive long enough to see it through.

OpenAI’s financial struggles aren’t unique. Many AI startups are facing the same challenges. But as the most visible player in the space, its fate will set the tone for the entire industry. If OpenAI stumbles, it won’t just be a company that fails. It will be a warning to everyone betting on the future of AI.

This post was originally published on my site. Read the full article and more →

Cursor’s Origin vs GitHub: What Developers Need to Know

Muhammad Adil — Wed, 19 Aug 2026 15:03:30 +0000

Cursor’s new Origin platform is making waves as the first serious GitHub alternative built by an AI-first team. If you’ve been using Cursor for coding assistance, Origin might feel like a natural next step. But should you actually move your repositories there? Let’s look at what works, what doesn’t, and where Origin fits in the landscape.

The Core Idea Behind Origin

Origin isn’t just another Git hosting service. It’s designed from the ground up to integrate with Cursor’s AI workflows. The pitch is simple: if you’re already using Cursor to write, debug, and refactor code, why not host your repos in a system that understands that workflow? The platform handles Git operations the same way GitHub does, but with tighter AI tooling baked in.

How It Stacks Up Against GitHub

No learning curve for Git commands. Origin uses the same CLI syntax as GitHub, so you won’t need to relearn anything.
Built-in AI code review. Origin can automatically suggest improvements during pull requests, something GitHub Copilot does but with less context about your repo’s history.
Private repos are free. Unlike GitHub, Origin doesn’t charge for private repositories, which could save teams money.
Fewer third-party integrations. GitHub’s marketplace is massive. Origin is new, so expect missing CI/CD, project management, and deployment tools for now.
Smaller community. GitHub has millions of public repos for reference. Origin’s ecosystem is still growing, so finding examples or forks might be harder.

Where Origin Shines

The biggest advantage is the AI-native experience. If you’re using Cursor, Origin can pull repo context directly into your editor. This means better autocomplete, more accurate refactoring suggestions, and fewer context-switching headaches. For teams already invested in Cursor, this alone might justify the switch.

Performance is another highlight. Origin’s interface feels snappier than GitHub’s, especially for large repos. The diff viewer and PR interface load quickly, which adds up when you’re reviewing code all day. There’s also no rate limiting on API calls, a common frustration with GitHub’s free tier.

The Biggest Limitations

Origin is still early. If you rely on GitHub Actions, Dependabot, or integrations like Slack or Jira, you’ll hit walls. The team has promised these features are coming, but for now, you’ll need workarounds or hybrid setups. There’s also no mobile app, which might be a dealbreaker for some.

Another consideration is lock-in. Origin’s AI features are compelling, but they’re also proprietary. If you ever want to move back to GitHub or another platform, you’ll lose those tight integrations. Exporting your repos is possible, but the AI-assisted workflows won’t come with you.

Who Should Switch?

Teams already using Cursor for most of their development. The AI integration is the killer feature here.
Developers frustrated with GitHub’s pricing. Origin’s free private repos are a clear win for small teams or solo devs.
Projects that don’t rely on GitHub’s ecosystem. If you’re not using Actions, Apps, or other integrations, the transition will be smoother.
Early adopters who want to shape a new platform. Origin’s team is actively gathering feedback, so now is the time to influence its direction.

Who Should Stay on GitHub

Teams with complex CI/CD pipelines. Origin’s lack of Actions support is a non-starter for many.
Open-source maintainers. GitHub’s community and discoverability are unmatched for public projects.
Companies using enterprise GitHub features. Origin doesn’t yet offer SAML, audit logs, or advanced security tools.
Developers who value stability over cutting-edge features. Origin is still evolving, and breaking changes are possible.

The Bottom Line

Origin isn’t a GitHub killer, at least not yet. It’s a strong alternative for a specific audience: developers who live in Cursor and want a version control system that plays nicely with AI. For everyone else, GitHub’s maturity and ecosystem still make it the safer choice.

If you’re curious, try Origin with a small side project. The free tier is generous, and you’ll quickly see whether the AI integrations justify the switch. For now, most teams will likely end up using both: GitHub for its stability and tools, Origin for its AI-powered workflows.

This post was originally published on my site. Read the full article and more →