DEV Community: Mohammed Chami

How to Authenticate GitHub Using SSH and Push Code Securely

Mohammed Chami — Fri, 08 Aug 2025 18:01:03 +0000

When working with GitHub, using HTTPS for pushing changes often asks for your username and password or personal access token every time. A better and more secure way is to use SSH authentication. This guide will show you how to generate an SSH key, add it to your GitHub account, and change your Git remote URL from HTTPS to SSH.

✅ Step 1: Check for Existing SSH Keys

Before generating a new SSH key, check if one already exists:

ls -al ~/.ssh

If you see files like id_rsa and id_rsa.pub or id_ed25519 and id_ed25519.pub, you already have SSH keys. You can skip to Step 3 if you want to use an existing key.

🛠️ Step 2: Generate a New SSH Key

If no key exists or you want to generate a new one, use the Ed25519 algorithm (recommended) or RSA as a fallback:

For Ed25519 (recommended):

ssh-keygen -t ed25519 -C "your_email@example.com"

For RSA (if Ed25519 isn't supported):

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

If ssh-keygen is not found, install OpenSSH:

# For Ubuntu/Debian
sudo apt update && sudo apt install openssh-client

# For Arch-based distros (e.g., EndeavourOS)
sudo pacman -S openssh

# For CentOS/RHEL/Fedora
sudo dnf install openssh-clients
# or for older versions: sudo yum install openssh-clients

When prompted:

Press Enter to accept the default location (~/.ssh/id_ed25519 or ~/.ssh/id_rsa)
Optionally enter a secure passphrase for extra protection

📋 Step 3: Add the SSH Key to the SSH Agent

Start the ssh-agent in the background:

eval "$(ssh-agent -s)"
eval (ssh-agent -c) // for fish

Then add your SSH private key to the agent:

For Ed25519:

ssh-add ~/.ssh/id_ed25519

For RSA:

ssh-add ~/.ssh/id_rsa

🔑 Step 4: Add the Public Key to GitHub

Copy your public key to the clipboard:

For Ed25519:

cat ~/.ssh/id_ed25519.pub

For RSA:

cat ~/.ssh/id_rsa.pub

Add to GitHub:

Go to GitHub.com → Click your profile picture → Settings
In the sidebar, click SSH and GPG keys
Click New SSH key
In the "Title" field, add a descriptive label (e.g., "My Linux Dev Machine")
Select Authentication Key as the key type
Paste your public key into the "Key" field
Click Add SSH key
If prompted, confirm access to your GitHub account

🧪 Step 5: Test Your SSH Connection

Verify that your SSH key is working correctly:

ssh -T git@github.com

Write Yes

Expected successful output:

Hi your_username! You've successfully authenticated, but GitHub does not provide shell access.

Troubleshooting common issues:

If you get a "Permission denied" error, double-check that your key was added correctly to GitHub
If you get a "Host key verification failed" error, run: ssh-keyscan github.com >> ~/.ssh/known_hosts

🔁 Step 6: Change Git Remote from HTTPS to SSH

Check your current remote URL:

git remote -v

If it shows HTTPS format:

origin  https://github.com/your_username/your_repo.git (fetch)
origin  https://github.com/your_username/your_repo.git (push)

Change it to SSH:

git remote set-url origin git@github.com:your_username/your_repo.git

Verify the change:

git remote -v

Should now show SSH format:

origin  git@github.com:your_username/your_repo.git (fetch)
origin  git@github.com:your_username/your_repo.git (push)

For multiple remotes:
If you have multiple remotes, you can change them individually:

git remote set-url upstream git@github.com:original_owner/original_repo.git

🚀 Step 7: Push Your Project

Now you can push your project securely over SSH:

git add .
git commit -m "Initial commit"
git push -u origin main

You won't be asked for a username or password again (unless you set a passphrase for your SSH key).

🔒 Security Best Practices

Use a strong passphrase for your SSH key
Keep your private key secure - never share it or commit it to a repository
Regularly rotate your SSH keys (recommended every 1-2 years)
Use different SSH keys for different services or environments
Enable two-factor authentication on your GitHub account for additional security

Good Luck

How to Check Disk Space in Linux (Terminal & GUI Methods)

Mohammed Chami — Thu, 24 Jul 2025 21:50:24 +0000

Managing disk space is essential for keeping your Linux system running smoothly. Whether you prefer the command line or graphical tools, here’s a straightforward guide to checking your free and used storage.

1. Quick Terminal Commands

Check Total Disk Usage (`df`)

The simplest way to see disk space across all partitions:

df -h

-h → Shows sizes in GB/MB (human-readable).
Key columns:
- Avail → Free space.
- Use% → Percentage used.

Example Output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  200G   50G  150G  25% /

Check Folder Sizes (`du`)

To see how much space a specific folder (like /home) is using:

du -sh ~/

-s → Summary (total size).
-h → Human-readable format.

Interactive Disk Usage Analyzer (`ncdu`)

For a more detailed breakdown, install ncdu:

sudo pacman -S ncdu
ncdu /

Navigate with arrow keys.
Sort by size (press n for name, s for size).
Delete files directly (press d).

2. Graphical Tools (For Desktop Users)

GNOME Disks (Default in GNOME)

Open "Disks" from the app menu.
Select your disk → View partition usage in the graph.

KDE Partition Manager (For KDE Plasma)

Install it:

   sudo pacman -S partitionmanager

Open Partition Manager → Check disk space visually.

File Manager (Thunar/Dolphin/Nautilus)

Open your file manager (e.g., Thunar in Xfce).
Right-click a drive → Properties → See free space.

3. Advanced: Finding Large Files

To locate large files (>100MB) in your home directory:

find ~/ -type f -size +100M -exec ls -lh {} \;

-type f → Files only (excludes folders).
-size +100M → Filters files larger than 100MB.

Summary: Which Method Should You Use?

Use Case	Recommended Tool	Command
Quick overview of all disks	`df -h`	`df -h`
Check a folder’s size	`du`	`du -sh ~/`
Interactive disk analysis	`ncdu`	`ncdu /`
GUI (GNOME)	Disks app	Open from Applications
GUI (KDE)	Partition Manager	`sudo pacman -S partitionmanager`
Find large files	`find`	`find ~/ -size +100M`

thank you :>|

Understanding Rendering in Programming: From Code to Pixels

Mohammed Chami — Tue, 08 Jul 2025 13:07:49 +0000

I remember the first time someone asked me to explain what "rendering" means in programming. I fumbled through a technical explanation about DOM trees and paint operations, and watched their eyes glaze over completely. That's when I realized I didn't really understand it myself - I just knew the buzzwords.

After years of debugging sluggish animations and optimizing app performance, I've learned that rendering is actually a pretty straightforward concept once you strip away the jargon. Let me explain it the way I wish someone had explained it to me.

What Is Rendering, Really?

At its core, rendering is just the process of turning your code into something visual on a screen. Think of it like a translator who takes your written instructions and turns them into pictures that users can actually see and interact with.

When you write HTML like <div style="color: red;">Hello World!</div>, something has to figure out how to display red text on the screen. That "something" is the rendering engine, and the process of making it happen is rendering.

It's essentially the bridge between the abstract world of code and the concrete world of pixels on a display.

How Different Systems Handle Rendering

Web Browsers and WebViews

When you load a webpage, your browser goes through what feels like a carefully choreographed dance:

First, it reads through your HTML and CSS to understand what you want to display. Then it calculates where everything should go on the page - this is called layout or reflow. Finally, it actually draws the pixels on your screen - the painting phase.

I've spent countless hours optimizing this process. The thing that surprised me most was learning that browsers don't just render once and call it done. Every time you scroll, resize the window, or interact with elements, parts of this process happen again. It's like having an artist constantly redrawing parts of a painting as you watch.

WebViews in hybrid apps work exactly the same way - they're essentially browsers without the address bar, running inside your mobile app.

Native Mobile Apps

Native apps take a more direct approach. When you build with Swift on iOS or Kotlin on Android, the operating system handles rendering using its own optimized systems. There's no HTML to parse or CSS to interpret - your code talks directly to the platform's UI framework.

This is why native apps often feel snappier than web-based alternatives. There are fewer translation layers between your code and the final pixels.

Cross-Platform Frameworks

Cross-platform tools like React Native and Avalonia UI have gotten creative with rendering. React Native translates your JavaScript components into native UI elements, so you get the performance benefits of native rendering while writing in familiar web technologies.

Avalonia UI takes a completely different approach. Instead of using platform UI components, it brings its own rendering engine (Skia) and draws everything from scratch. It's like bringing your own paintbrush to an art class instead of using the ones provided.

The Performance Connection

Here's where rendering becomes crucial for developers: poor rendering performance is often the culprit behind sluggish apps.

I learned this lesson while working on a data-heavy dashboard that worked fine with small datasets but became unusable with real-world data. The problem wasn't the data processing - it was that we were forcing the browser to re-render thousands of DOM elements every time something changed.

The solution was understanding how rendering works and optimizing accordingly. We implemented virtual scrolling, batched updates, and learned to work with the browser's rendering pipeline instead of against it.

Common Rendering Scenarios

Server-Side Rendering (SSR) happens when your HTML is generated on the server before being sent to the browser. This is great for initial page loads and SEO, but it means your server is doing the heavy lifting.

Client-Side Rendering (CSR) is when your JavaScript generates the HTML in the browser. This enables more interactive experiences but can make initial page loads slower.

GPU Rendering comes into play for games and graphics-intensive applications. Instead of using your computer's main processor, rendering work gets handed off to the graphics card, which is optimized for this kind of parallel processing.

Why This Matters for Developers

Understanding rendering helps you make better architectural decisions. When you know that every DOM manipulation potentially triggers a re-render, you start thinking differently about how to structure your updates.

It also helps with debugging. When users report that your app feels "janky" or slow, rendering performance is often the first place to look. Modern browser dev tools make it easy to profile rendering performance and identify bottlenecks.

For mobile development, rendering efficiency directly impacts battery life. Apps that cause excessive re-renders or use inefficient rendering techniques will drain batteries faster - something users definitely notice.

The Practical Takeaway

Rendering is everywhere in modern software development. Whether you're building a simple website, a complex mobile app, or a real-time game, something somewhere is taking your code and turning it into pixels on a screen.

The key insight is that rendering isn't just a technical detail - it's a fundamental part of user experience. Smooth, efficient rendering makes apps feel responsive and professional. Poor rendering makes even the best-designed applications feel broken.

Understanding the basics of how rendering works in your chosen platform will make you a better developer. You'll write more efficient code, debug performance issues faster, and build applications that feel great to use.

Next time you're working on a project, take a moment to think about the rendering pipeline. What's happening between your code and the user's screen? Understanding that journey is the difference between code that works and code that works well.

Understanding Hybrid Apps and WebViews: What Every Developer Should Know

Mohammed Chami — Mon, 07 Jul 2025 16:22:59 +0000

When I first heard about "hybrid apps," I thought it was just marketing speak for "apps that don't work properly on either platform." I was partially right, but also completely wrong. After building several hybrid applications and debugging countless WebView issues, I've learned that hybrid development is both more clever and more limited than I initially understood.

Let me break down what's actually happening under the hood when you build a hybrid app, and why understanding WebViews is crucial for any mobile developer.

What Are Hybrid Apps Really?

The term "hybrid app" sounds fancy, but the concept is straightforward: take a web application you've already built, wrap it in a minimal native app shell, and distribute it through app stores. Think of it as putting your website in a native costume and teaching it to speak to the phone's hardware.

Here's the basic architecture:

The native shell handles the boring stuff—app store distribution, permissions, device integration—while your familiar web technologies handle the user interface and business logic. It's like having a native app that's really good at pretending to be a web browser.

The WebView: Your App's Secret Browser

Understanding WebViews is crucial because they're the magic ingredient that makes hybrid apps possible. A WebView is essentially a browser engine stripped of everything that makes it obviously a browser—no address bar, no tabs, no bookmarks—just the rendering engine.

When users interact with your hybrid app, they're actually interacting with a web page that's been embedded inside a native application. Every tap, scroll, and animation is being processed by the same engine that renders websites, just packaged differently.

Platform Differences Matter

Here's where things get interesting: WebViews aren't created equal across platforms. On Android, you're using Chromium's Blink engine (the same one that powers Chrome). On iOS, you're using WebKit (Safari's engine). This means your app might behave differently on each platform, even though you're using the same code.

I learned this the hard way when an animation that worked perfectly on iOS devices stuttered terribly on Android. The CSS transforms I was using hit a performance bottleneck in the Android WebView that didn't exist in Safari's engine. Same code, different results.

The Performance Reality Check

Let's be honest about performance: hybrid apps are slower than native apps for most interactions. There's no getting around this fundamental limitation. When a user taps a button in your hybrid app, here's what actually happens:

The native touch event gets captured
It's passed to the WebView
The WebView processes it through its JavaScript engine
Your app logic executes
The DOM updates
The WebView re-renders the affected elements
The result appears on screen

Compare this to a native app where the touch event goes directly to the native UI component and updates immediately. The difference is measurable, and for complex interactions, it's noticeable.

However, for many types of apps—forms, dashboards, content readers—this performance difference is negligible. Users don't notice the extra milliseconds unless you're doing something intensive like real-time animations or handling large datasets.

When Hybrid Apps Make Sense

Despite the performance limitations, hybrid apps have carved out a legitimate niche. They're particularly effective for:

Content-heavy applications where users are primarily reading, browsing, or filling out forms. News apps, documentation viewers, and survey tools work great as hybrid apps.

Rapid prototyping when you need to test an idea across platforms quickly. Being able to deploy the same codebase to iOS, Android, and the web simultaneously is incredibly valuable during the validation phase.

Teams with strong web expertise but limited native mobile experience. If your developers are experts in React or Vue but have never touched Swift or Kotlin, hybrid development can be a practical bridge.

Apps that need frequent updates to content or business logic. Web technologies make it easier to push updates without going through app store review processes.

The Development Experience

Building hybrid apps feels familiar if you're coming from web development, but there are mobile-specific considerations you can't ignore. You're still dealing with touch interfaces, different screen sizes, and platform-specific behaviors, even though you're using web technologies.

The debugging experience is more complex than pure web development. When something goes wrong, you might need to debug through your JavaScript code, the plugin bridge, and potentially native platform code. Modern tools like Chrome DevTools integration with WebViews have made this much more manageable, but it's still more layers than a typical web app.

The Plugin Ecosystem

One of hybrid development's biggest advantages is the plugin ecosystem. Need to access the camera? There's a plugin for that. Want to use push notifications? Plugin. GPS, accelerometer, contacts, file system—plugins handle the bridge between your JavaScript code and native device capabilities.

Frameworks like Cordova and Capacitor have mature plugin ecosystems that cover most common use cases. When you need something custom, you can write your own plugins, though this requires some native development knowledge.

Common Pitfalls I've Encountered

Assuming web performance translates to mobile performance. Animations that run smoothly in desktop browsers might stutter in mobile WebViews. Always test on actual devices, not just simulators.

Ignoring platform-specific UI conventions. Just because you can make your app look identical on iOS and Android doesn't mean you should. Users have platform-specific expectations.

Over-engineering the plugin bridge. It's tempting to create elaborate communication systems between JavaScript and native code, but simpler approaches usually work better and are easier to debug.

Forgetting about WebView security. WebViews can be vulnerable to the same security issues as web browsers. Always sanitize user input and be careful about what external content you load.

The Future of Hybrid Development

The line between hybrid and other development approaches continues to blur. Progressive Web Apps are becoming more capable, while frameworks like Ionic have evolved to use modern web technologies like Web Components. Meanwhile, the WebView engines themselves are getting faster and more capable.

Apple's recent improvements to iOS WebViews and Android's continued investment in Chromium mean that the performance gap between hybrid and native apps is narrowing for many use cases.

Making the Right Choice

Hybrid app development isn't the right choice for every project, but it's not the wrong choice for every project either. The key is understanding your specific constraints and requirements.

If you're building a game, a photo editor, or anything that requires intensive real-time interactions, native development is probably worth the extra investment. If you're building a business app, a content reader, or a tool that's primarily about displaying and collecting information, hybrid development can be both practical and cost-effective.

The most successful hybrid apps I've worked on were built by teams that understood both the capabilities and limitations of the approach. They designed their user experiences around what WebViews do well, rather than fighting against what they don't do well.

Final Thoughts

Hybrid app development gets a bad reputation because it's often chosen for the wrong reasons—usually as a cost-cutting measure rather than a strategic technical decision. When approached thoughtfully, with realistic expectations about performance and user experience, hybrid apps can be a powerful tool for reaching users across platforms efficiently.

The key is being honest about trade-offs. You're trading some performance and platform-specific polish for development efficiency and code reuse. For many projects, that's a worthwhile exchange.

Understanding App Development Approaches: A Developer's Guide to Native, Cross-Platform, Hybrid, and PWA

Mohammed Chami — Mon, 07 Jul 2025 16:00:34 +0000

When I first started developing applications, the sheer number of development approaches available was overwhelming. Should I build native apps for each platform? Try a cross-platform framework? Go with a hybrid solution? Or maybe consider a Progressive Web App? Each approach has its place, and understanding their strengths and weaknesses can save you months of development time and thousands of dollars in project costs.

After working with all these approaches across various projects, I've learned that the "best" choice depends entirely on your specific requirements, timeline, and budget. Let me break down each approach and help you understand when to use which.

Native App Development

Native development means building applications specifically for one platform using that platform's official tools and programming languages. For iOS, you'd use Swift or Objective-C with Xcode. For Android, you'd use Kotlin or Java with Android Studio.

Think of native development as speaking the platform's native language fluently. When you build natively, you're working directly with the operating system's APIs and frameworks, which gives you unparalleled access to device capabilities and performance optimization.

When Native Makes Sense

I typically recommend native development for apps that need to squeeze every bit of performance from the device. Gaming apps, augmented reality experiences, and applications with complex animations benefit enormously from native development. If your app needs to access specialized hardware features or integrate deeply with the operating system, native is often your only viable option.

The user experience also tends to be superior with native apps. They follow platform-specific design guidelines naturally, making them feel "at home" on each device. Users can immediately tell when an app was built natively versus when it's trying to mimic native behavior.

The Native Trade-offs

The biggest drawback is obvious: you need separate codebases for each platform. This means hiring developers with different skill sets, maintaining multiple projects, and essentially building your app twice (or more if you're targeting additional platforms). The development timeline extends significantly, and costs can quickly spiral.

However, for companies with the resources and long-term vision, native development often pays off in user satisfaction and app performance metrics.

Cross-Platform App Development

Cross-platform frameworks like React Native, Flutter, and Avalonia promise something that sounds almost too good to be true: write your app once, deploy it everywhere. After shipping apps with each of these frameworks, I can tell you they largely deliver on this promise, but the devil is in the details.

The fundamental insight behind cross-platform development is that you can share business logic and UI structure between platforms while still producing apps that feel genuinely native. It's like having a translator who doesn't just convert words but understands the cultural context behind them.

How the Magic Actually Works

Different frameworks take dramatically different approaches to solving the cross-platform puzzle, and understanding these differences is crucial for choosing the right tool.

React Native's Bridge Strategy:
React Native acts as a diplomatic bridge between JavaScript and native code. When you write a <View> component, React Native doesn't render it as HTML - it maps directly to a UIView on iOS or a ViewGroup on Android. Your JavaScript business logic runs in one thread while the native UI renders in another, with messages passing back and forth through what's called "the bridge."

This architecture means your app is genuinely using native components, not simulating them. When users scroll through a list, they're interacting with actual native scroll views, complete with platform-specific physics and behaviors.

Flutter's Compiled Approach:
Flutter takes a completely different philosophy. Instead of bridging to native components, it brings its own rendering engine (Skia) and draws everything from scratch. Think of it as a game engine for UI - it controls every pixel on the screen.

Your Dart code compiles directly to native ARM assembly, eliminating the JavaScript bridge entirely. When Flutter renders a button, it's not using iOS's UIButton or Android's Button - it's drawing what looks like those buttons using its own graphics primitives.

Avalonia's Custom Rendering Approach:
Avalonia takes yet another path entirely. Like Flutter, it uses its own rendering engine (Skia) to draw everything from scratch, but it's built for the .NET ecosystem using C# and XAML. Think of it as bringing WPF's development model to every platform - you get the same UI framework whether you're targeting Windows, macOS, Linux, or even mobile platforms.

Unlike React Native's component mapping or Flutter's widget system, Avalonia renders using familiar .NET patterns. Your XAML layouts and C# code-behind work exactly the same way across all platforms because Avalonia is literally drawing the same pixels everywhere.

The Performance Reality

After benchmarking these frameworks across various scenarios, here's what I've observed:

For typical business apps - forms, lists, navigation - the performance difference between cross-platform and native is negligible. Users simply can't tell the difference. Where you start to notice gaps is in edge cases: complex animations with hundreds of elements, real-time graphics processing, or apps that push the boundaries of what mobile hardware can handle.

React Native's bridge introduces some overhead, but Facebook's engineers have optimized it extensively. The bigger performance consideration is actually JavaScript execution speed, not bridge latency. Modern JavaScript engines are remarkably fast, and React Native includes optimizations like native animation drivers that bypass the bridge entirely for smooth animations.

Flutter's compiled approach often delivers performance that's indistinguishable from native. Since everything compiles to native code and the rendering engine is highly optimized, you're essentially running a native app that happens to be written in Dart instead of Swift or Kotlin.

Avalonia's performance sits somewhere between React Native and Flutter. Since it uses Skia for GPU-accelerated rendering like Flutter, you get smooth animations and pixel-perfect control. However, running on the .NET runtime adds some overhead compared to Flutter's ahead-of-time compilation. In practice, this difference is rarely noticeable for typical business applications.

The Developer Experience Difference

Building cross-platform apps requires a different mindset than web development. You're not just making a website responsive - you're thinking about platform conventions, navigation patterns, and user expectations that vary between iOS and Android.

The debugging experience is more complex too. When something goes wrong, you might need to trace through your application code, the framework's bridge layer, and potentially native platform code. Modern developer tools have improved significantly, but there's still more complexity than pure native development.

However, the productivity gains are substantial. Being able to implement a feature once and see it work across platforms is genuinely satisfying. The iteration speed during development is typically faster than native development because you're not context-switching between different IDEs, languages, and toolchains.

When Cross-Platform Shines

I recommend cross-platform development when:

You have a clear product-market fit and need to reach users quickly across platforms
Your team has stronger web/JavaScript skills than native mobile experience
You're building a content-heavy app rather than a games or graphics-intensive application
You want to maintain feature parity across platforms without doubling development effort

The approach works particularly well for apps that follow standard mobile patterns: tab navigation, lists, forms, and basic animations. If your app could be described as "standard mobile app functionality with custom business logic," cross-platform is probably ideal.

The Limitations to Consider

Cross-platform development becomes challenging when:

You need cutting-edge platform features that aren't yet supported by the framework
Your app requires extensive platform-specific UI customization
You're building games or graphics-intensive applications
You need to integrate with complex native libraries or SDKs

The most common frustration I encounter is when designers create mockups that look identical across platforms but violate platform-specific conventions. iOS users expect certain navigation patterns, Android users expect others, and sometimes "write once, run everywhere" conflicts with "design for the platform."

The Ecosystem Maturity

The cross-platform ecosystem has matured significantly. React Native powers apps like Facebook, Instagram, and Airbnb. Flutter is used by Google Pay, BMW, and Alibaba. Avalonia is gaining traction in enterprise applications where teams want to leverage existing .NET expertise across desktop and mobile platforms. These aren't toy frameworks - they're production-ready tools used by companies with millions of users.

The third-party library ecosystem is robust, though not as comprehensive as native development. Most common functionality is available through community packages, but occasionally you'll need to write native bridge code for specialized requirements.

Making the Decision

Cross-platform development has evolved from a compromise to a legitimate first choice for many projects. The performance trade-offs are minimal for most applications, the development efficiency gains are substantial, and the ecosystem is mature enough to support complex applications.

The key is being honest about your specific requirements. If you're building a straightforward business app and want to reach market quickly, cross-platform is often the optimal choice. If you're building the next breakthrough mobile game or need to push the boundaries of what mobile hardware can do, native development might be worth the additional investment.

Hybrid App Development

Hybrid development represents the web developer's entry point into mobile app development. Using frameworks like Ionic, Cordova, or Capacitor, you build your app using familiar web technologies (HTML, CSS, JavaScript) and then wrap it in a native container.

Understanding WebView

Here's where technical understanding becomes crucial. Hybrid apps run inside what's called a WebView - essentially a browser window embedded within a native app shell. When users interact with your hybrid app, they're actually interacting with a web page that's been packaged to look and feel like a native app.

This WebView approach has both advantages and limitations. On the positive side, you can leverage your existing web development skills and build for multiple platforms simultaneously. The challenge is that you're fundamentally limited by the performance characteristics of the WebView itself.

The Rendering Pipeline

When a user taps a button in your hybrid app, that interaction must travel through several layers: the native touch event gets passed to the WebView, which then processes it through the web rendering engine, executes your JavaScript, potentially updates the DOM, and finally renders the result back to the screen.

This multi-step process introduces latency that native apps don't experience. For simple interactions, this delay is negligible. For complex interfaces or animations, it becomes noticeable.

Progressive Web Apps (PWA)

PWAs represent an evolution of web applications that blurs the line between web and native experiences. They're built with standard web technologies but include features traditionally associated with native apps: offline functionality, push notifications, and the ability to be installed on the home screen.

Service Workers: The Game Changer

The magic of PWAs comes from Service Workers - JavaScript files that run in the background, separate from your main web page. Think of them as a proxy server that sits between your web app and the network. They can intercept network requests, serve cached content when offline, and handle background tasks like push notifications.

This architecture enables PWAs to work offline in ways that traditional web apps cannot. When you visit a PWA for the first time, the Service Worker downloads and caches essential resources. On subsequent visits, even without internet connectivity, the app can still function using cached data.

The Installation Experience

Modern browsers allow PWAs to be "installed" directly from the browser without going through an app store. This creates an interesting distribution model where users can discover your app through web searches and install it immediately, bypassing the traditional app store approval process.

However, this also means PWAs miss out on the discoverability benefits of app stores. Users don't typically browse for PWAs the way they browse for native apps.

Performance Considerations

Understanding performance differences requires looking at how each approach handles the rendering pipeline - the process of turning your code into pixels on the screen.

Native apps have the most direct path to the screen. When you update a native UI element, it communicates directly with the platform's rendering system. Cross-platform frameworks add a translation layer but often compile to native code, minimizing overhead.

Hybrid apps face the biggest performance challenge because they must render through the WebView's HTML/CSS engine, which then gets composited with native UI elements. PWAs run entirely within the browser's rendering engine, which can be highly optimized but may not match native performance for complex interactions.

Making the Right Choice

The decision usually comes down to a few key factors:

Performance requirements: If your app needs to handle complex animations, real-time interactions, or intensive computational tasks, native development typically provides the best results.

Development timeline: Cross-platform and hybrid approaches can significantly reduce development time, especially if you have web development expertise.

Budget constraints: PWAs offer the lowest development costs, while native development typically requires the largest investment.

Target audience: Consider how your users will discover and interact with your app. PWAs excel at immediate accessibility, while native apps provide the best integration with device ecosystems.

Long-term maintenance: Native apps require maintaining separate codebases, while cross-platform solutions let you fix bugs and add features once for all platforms.

The Future Landscape

The boundaries between these approaches continue to blur. Apple's recent changes to iOS make PWAs more capable, while frameworks like Flutter are pushing cross-platform performance closer to native levels. Meanwhile, technologies like WebAssembly are improving web app performance dramatically.

Rather than viewing these as competing approaches, I've found it helpful to think of them as tools in a toolkit. The best developers understand the strengths and limitations of each approach and can recommend the right solution for each specific project.

Conclusion

There's no universally "correct" choice among these development approaches. I've seen successful apps built with each method, and I've also seen projects fail because they chose the wrong approach for their specific requirements.

The key is understanding your priorities: performance vs. development speed, native integration vs. cross-platform reach, app store distribution vs. web accessibility. Once you're clear on these priorities, the right approach usually becomes obvious.

Remember that you're not locked into your initial choice forever. Many successful apps have evolved from one approach to another as their requirements and resources changed. The important thing is making an informed decision based on your current needs and constraints.

Checking Your .NET Installation (SDK and RunTime): A Quick Guide

Mohammed Chami — Mon, 07 Jul 2025 14:38:56 +0000

Whether you're just starting with .NET development or troubleshooting an existing project, one of the first things you'll need to know is what versions of the .NET SDK and runtime are installed on your machine. This information becomes crucial when dealing with compatibility issues, setting up new projects, or collaborating with team members who might be using different versions.

The Quick Commands You Need

Fortunately, Microsoft made this process straightforward with a few simple commands that work across Windows, macOS, and Linux.

Checking Installed SDKs

To see all .NET SDKs installed on your system, open your terminal or command prompt and run:

dotnet --list-sdks

This command will show you something like:

6.0.405 [C:\Program Files\dotnet\sdk]
7.0.102 [C:\Program Files\dotnet\sdk]
8.0.100 [C:\Program Files\dotnet\sdk]

Each line shows the SDK version followed by its installation path. The SDK is what you need for developing .NET applications - it includes the compiler, tools, and libraries necessary to build your projects.

Checking Installed Runtimes

To see all .NET runtimes on your system, use:

dotnet --list-runtimes

You'll get output similar to:

Microsoft.AspNetCore.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

The runtime is what's needed to actually run .NET applications. You might notice different types of runtimes listed - these serve different purposes:

Microsoft.NETCore.App: The base runtime for console and server applications
Microsoft.AspNetCore.App: Additional components for web applications
Microsoft.WindowsDesktop.App: Components for Windows desktop applications (WPF, WinForms)

The All-in-One Command

If you want a comprehensive overview of your .NET installation, there's a single command that provides everything:

dotnet --info

This command gives you detailed information about your entire .NET environment, including:

The currently active SDK version
All installed SDKs and runtimes
Runtime environment details
Operating system information

The output is quite verbose, but it's incredibly useful when you need to provide environment details for bug reports or when working with support teams.

Understanding the Output

When you run these commands, you might see multiple versions installed. This is completely normal and actually beneficial - .NET supports side-by-side installations, meaning you can have multiple versions coexisting without conflicts.

The .NET CLI will automatically select the appropriate SDK version based on your project's configuration. If you have a global.json file in your project, it will use the SDK version specified there. Otherwise, it defaults to the latest installed version.

Common Scenarios

Starting a New Project

Before creating a new .NET project, check your available SDKs to ensure you're using the version you want. If you need a specific version for compatibility reasons, you can specify it in a global.json file.

What If Nothing Is Installed?

If you run these commands and get a message like "command not found" or "dotnet is not recognized," it means the .NET CLI isn't installed on your system. You can download it from Microsoft's official .NET website.

Keeping Track of Versions

Different projects might target different .NET versions, and that's okay. The beauty of .NET's side-by-side installation model is that you can maintain multiple projects with different framework requirements without conflicts.

If you find yourself frequently switching between different .NET versions for various projects, consider keeping a simple text file or note with the versions each project requires. This can save time when you return to older projects months later.

Final Thoughts

These simple commands are among the most useful in any .NET developer's toolkit. Whether you're debugging a mysterious build issue, setting up a new development environment, or just satisfying your curiosity about what's installed on your machine, these commands will quickly give you the information you need.

Remember that having multiple versions installed is normal and often necessary, especially if you're maintaining applications that target different .NET versions. The key is understanding what you have available and how to use that information effectively in your development workflow.

Connecting to Your Android Device via SSH from Linux: A Complete Termux Guide

Mohammed Chami — Mon, 07 Jul 2025 14:11:02 +0000

Ever wanted to access your Android phone's terminal from your Linux desktop? Whether you're transferring files, running commands remotely, or just exploring your device's capabilities, SSH access opens up a world of possibilities. However, getting that initial connection working can be frustrating when you're met with cryptic "Access Denied" errors.

This guide will walk you through setting up a reliable SSH connection between your Pop!_OS machine and Android device using Termux, troubleshooting common issues, and ensuring secure access.

Why SSH to Android?

SSH access to your Android device transforms how you interact with it. You can transfer files without cables, run automated scripts, access your phone's filesystem, and even use it as a development environment. It's particularly useful for developers, system administrators, and anyone who prefers command-line efficiency.

Setting Up Termux for SSH Access

Installing and Configuring Termux

Termux stands out as the most capable terminal emulator for Android. Unlike other solutions, it provides a genuine Linux environment with package management and full SSH server capabilities.

Download Termux from F-Droid rather than Google Play. The F-Droid version receives more frequent updates and has fewer restrictions.

Once installed, open Termux and update the package repositories:

pkg update && pkg upgrade

This ensures you have the latest security patches and features.

Installing OpenSSH Server

Install the OpenSSH server package:

pkg install openssh

Termux's OpenSSH implementation is full-featured and includes all the security features you'd expect from a modern SSH server.

Starting the SSH Service

Launch the SSH daemon:

sshd

The SSH server will start immediately and begin listening for connections. Unlike traditional Linux systems, Termux doesn't use systemd, so the service won't automatically restart on reboot.

Finding Your Android's Network Address

Determine your Android device's IP address:

ip addr show wlan0

Look for the inet line under the wlan0 interface. You'll see something like 192.168.1.155/24 - the IP address is the part before the slash.

Understanding Termux SSH Configuration

Port Configuration

Here's where many people get stuck: Termux uses port 8022 for SSH, not the standard port 22. This is because Android's security model prevents non-system apps from binding to privileged ports (those below 1024).

Your SSH command will look like this:

ssh -p 8022 [username]@[ip_address]

Username Discovery

Termux uses Android's internal username system. Find your username by running:

whoami

You'll see something like u0_a123 - this is your Android user ID that you'll need for SSH connections.

Configuring Authentication

The Password Authentication Challenge

By default, Termux disables password authentication for security reasons. Most SSH "Access Denied" errors stem from this configuration.

To enable password authentication for testing purposes, first set a password:

passwd

Then edit the SSH configuration:

nano $PREFIX/etc/ssh/sshd_config

Find the line containing PasswordAuthentication and change it to:

PasswordAuthentication yes

If the line doesn't exist, add it to the file.

Restart the SSH service:

pkill sshd && sshd

Testing the Connection

Now attempt to connect from your Pop!_OS machine:

ssh -p 8022 u0_a123@192.168.1.155

Replace u0_a123 with your actual username and 192.168.1.155 with your Android's IP address.

Setting Up Key-Based Authentication

Why Use SSH Keys?

Password authentication works for testing, but key-based authentication is more secure and convenient. Once set up, you won't need to enter passwords for each connection.

Generating SSH Keys

On your Pop!_OS machine, generate an SSH key pair if you don't already have one:

ssh-keygen -t ed25519 -C "your_email@example.com"

The Ed25519 algorithm provides excellent security with smaller key sizes compared to RSA.

Copying Keys to Android

The easiest method is using ssh-copy-id:

ssh-copy-id -p 8022 u0_a123@192.168.1.155

This command automatically copies your public key to the Android device's authorized keys file.

If ssh-copy-id fails, you can manually copy the key:

cat ~/.ssh/id_ed25519.pub | ssh -p 8022 u0_a123@192.168.1.155 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

Disabling Password Authentication

For better security, disable password authentication once key-based auth is working:

nano $PREFIX/etc/ssh/sshd_config

Change or add:

PasswordAuthentication no

Restart the SSH service:

pkill sshd && sshd

Troubleshooting Common Issues

Connection Refused Errors

If you get "Connection refused," the SSH service isn't running or isn't listening on the expected port. Check if the service is running:

pgrep sshd

If no process ID appears, start the service again:

sshd

Network Connectivity Problems

Ensure both devices are on the same WiFi network. Test basic connectivity:

ping 192.168.1.155

If ping fails, you have a network issue rather than an SSH problem.

Permission Denied with Keys

If key authentication fails, check the key permissions on both devices:

# On Pop!_OS
ls -la ~/.ssh/
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

On Android (via Termux):

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/authorized_keys

Automating SSH Server Startup

Creating a Startup Script

Since Termux doesn't automatically start SSH on boot, create a simple script:

nano ~/start_ssh.sh

Add:

#!/data/data/com.termux/files/usr/bin/bash
sshd
echo "SSH server started on port 8022"

Make it executable:

chmod +x ~/start_ssh.sh

Using Termux:Boot

For automatic startup, install the Termux:Boot add-on from F-Droid. Create a startup script in the required directory:

mkdir -p ~/.termux/boot/
echo 'sshd' > ~/.termux/boot/start_ssh
chmod +x ~/.termux/boot/start_ssh

Advanced Configuration

Custom SSH Configuration

Create an SSH config file on your Pop!_OS machine for easier connections:

nano ~/.ssh/config

Add:

Host android-phone
    HostName 192.168.1.155
    Port 8022
    User u0_a123
    IdentityFile ~/.ssh/id_ed25519

Now you can connect simply with:

ssh android-phone

File Transfer Operations

Use SCP for file transfers:

scp -P 8022 file.txt u0_a123@192.168.1.155:~/

Or use rsync for more advanced synchronization:

rsync -avz -e "ssh -p 8022" ~/Documents/ u0_a123@192.168.1.155:~/backup/

Security Considerations

Firewall Configuration

Consider enabling UFW on your Pop!_OS machine and configuring appropriate rules:

sudo ufw allow from 192.168.1.0/24 to any port 22

Regular Security Updates

Keep both systems updated:

# Pop!_OS
sudo apt update && sudo apt upgrade

# Termux
pkg update && pkg upgrade

Conclusion

Setting up SSH access between Pop!_OS and Android via Termux opens up powerful possibilities for file management, remote administration, and development workflows. The key is understanding Termux's unique port configuration and authentication requirements.

Remember that the SSH server in Termux won't survive app kills or device reboots, so you'll need to restart it periodically. Consider this when planning automated workflows or remote access scenarios.

With proper configuration, you'll have a secure, efficient way to access your Android device's terminal from your Linux desktop, making cross-device development and file management significantly easier.

Building WordPress Sites Locally with Elementor on Linux: A Complete Guide

Mohammed Chami — Sun, 06 Jul 2025 23:45:05 +0000

Setting up a local WordPress development environment has become essential for anyone serious about web design. Whether you're building client websites, testing new ideas, or just learning the ropes, having a local setup saves time, money, and prevents the embarrassment of breaking a live site.

This guide will walk you through creating a powerful local WordPress development environment on Linux using Elementor's drag-and-drop interface. You'll be able to design and test your websites completely offline before taking them live.

Why Choose Local Development?

Working locally offers several advantages over developing directly on live servers. You can experiment freely without worrying about downtime, test plugins and themes without affecting visitors, and work without an internet connection. Plus, local development is significantly faster since everything runs on your own machine.

The combination of WordPress and Elementor gives you professional-grade website building capabilities. WordPress provides the robust content management system, while Elementor adds an intuitive visual editor that rivals premium website builders.

Setting Up Your Local Environment

The Easy Route: Using Local by Flywheel

Local by Flywheel (now simply called "Local") has become the go-to solution for WordPress developers. It handles all the server configuration automatically, so you can focus on building rather than debugging Apache configurations.

First, head over to localwp.com and download the Linux version. You'll get a .deb file that installs cleanly on Linux.

Once downloaded, install it through the terminal:

sudo dpkg -i ~/Downloads/local-5.2.3-linux-*.deb
sudo apt --fix-broken install

for arch linux:

yay -Ss flywheel

you will get this:

aur/local-by-flywheel-bin 9.2.4-6788 (+22 0.18)
    A program to create a local WordPress development environment.

to install do this:

yay -Sy local-by-flywheel-bin 9.2.4-6788

The second command fixes any dependency issues that might arise during installation.

Creating Your First Local Site

Launch Local from your applications menu. The interface is refreshingly clean and straightforward.

Click "Create a New Site" and you'll be guided through a simple setup process:

Site Name: Choose something descriptive like "MyPortfolio" or "ClientProject"
Environment: The default "Preferred" option works well for most projects
WordPress Credentials: Set up your admin username and password (write these down!)

Local handles all the behind-the-scenes work - setting up the database, configuring PHP, and installing WordPress. In just a few minutes, you'll have a fully functional WordPress site running on your machine.

Installing Elementor

With your local WordPress site ready, it's time to add Elementor's design capabilities. Click "WP Admin" in Local to open your WordPress dashboard.

Navigate to Plugins → Add New and search for "Elementor". Install and activate both the free Elementor plugin and Elementor Pro if you have a license. The free version provides plenty of functionality for most projects.

Designing with Elementor

Getting Started with the Visual Editor

Elementor transforms WordPress from a traditional CMS into a visual design tool. Create a new page or edit an existing one, then click "Edit with Elementor" to launch the visual editor.

The interface is divided into three main areas:

Left Panel: Contains all your widgets and design elements. You'll find everything from basic text blocks to complex carousel sliders and contact forms.

Center Canvas: This is your live preview area where you drag and drop elements. What you see here is exactly what your visitors will see.

Right Panel: Controls styling and content for whatever element you have selected. This is where you'll adjust colors, fonts, spacing, and other design details.

Building Your First Page

Start by dragging a section from the left panel onto your canvas. Sections act as containers for your content and help organize your page layout.

Within each section, you can add columns to create multi-column layouts. Then populate these columns with widgets like text boxes, images, buttons, and more complex elements.

The real power of Elementor shows when you start styling these elements. Select any widget and the right panel fills with customization options. You can adjust typography, colors, spacing, animations, and responsive behavior without touching a line of code.

Responsive Design Made Easy

One of Elementor's strongest features is its responsive editing capabilities. At the bottom of the editor, you'll find device icons that let you preview and adjust your design for desktop, tablet, and mobile devices.

Make sure to test your design on all screen sizes. What looks perfect on desktop might need adjustments on mobile devices.

Taking Your Site Live

Preparing for Migration

When you're satisfied with your local development, it's time to move your site to a live server. This process involves transferring both your WordPress files and database.

From your Local environment, you can export your site in several ways. The simplest approach is using Local's built-in export feature, which creates a package containing everything needed for your site.

Database and File Transfer

If you prefer manual control over the process, you can export your database directly:

mysqldump -u wpuser -p wordpress > wordpress_backup.sql

Then compress your WordPress files:

tar -czvf wordpress_site.tar.gz /var/www/html/wordpress

Migration Tools

For a more streamlined approach, consider using migration plugins like "All-in-One WP Migration" or "Duplicator". These tools handle the entire process automatically, including updating URLs and file paths.

Most hosting providers also offer WordPress-specific migration tools that can import your local site directly.

Troubleshooting Common Issues

Local Won't Start

If Local refuses to launch, try a clean reinstall:

sudo apt remove local
sudo apt autoremove
sudo dpkg -i local-linux-*.deb

Sometimes conflicting Apache or MySQL installations can interfere with Local. Check if you have other web servers running and stop them if necessary.

Elementor Performance Issues

If Elementor feels sluggish, check your PHP version. WordPress and Elementor perform best with PHP 7.4 or newer:

sudo apt install php8.1

Also, ensure your Local site has adequate memory allocation. You can adjust this in Local's site settings.

Plugin Conflicts

If you encounter unexpected behavior, try deactivating all plugins except Elementor, then reactivate them one by one to identify conflicts.

Best Practices for Local Development

Keep your local environment updated regularly. Both Local and WordPress release security and performance updates frequently.

Use version control (like Git) to track changes in your custom themes and plugins. This makes it easier to collaborate with others and roll back problematic changes.

Create a standardized development workflow. Install the same plugins and themes you use on live sites to ensure consistency.

Conclusion

Setting up a local WordPress development environment with Elementor gives you professional-grade website building capabilities without the complexity of server management. You can experiment freely, work offline, and develop sites faster than ever before.

The combination of Local's simplicity and Elementor's visual design tools makes this setup accessible to beginners while providing the power that professional developers need. Whether you're building your first website or your hundredth, this local development approach will streamline your workflow and improve your results.

Turn Your Android Phone into a Virtual Webcam for OBS on Linux (Without DroidCam)

Mohammed Chami — Sat, 05 Jul 2025 22:02:13 +0000

If you're tired of dealing with DroidCam's WiFi-only limitations or want a more reliable USB connection for streaming, this guide will show you how to transform your Android phone into a high-quality virtual webcam for OBS Studio on Linux systems like Pop!_OS.

Why This Method Works Better

After struggling with DroidCam's WiFi connectivity issues, I discovered this USB-based approach that delivers near-zero latency and crisp video quality. While you'll need a separate microphone for audio (or can set up PulseAudio loopback), the video quality improvement is worth it.

example:

in OBS:

This solution creates a proper virtual webcam device (/dev/videoX) that OBS and other applications can recognize as a standard camera input.

The Technical Stack

Our setup uses three key components working together:

scrcpy - Originally designed for Android screen mirroring and remote control, we're repurposing it to stream your phone's camera feed over USB with minimal latency.

v4l2loopback - This kernel module creates a virtual video device that acts as a bridge between scrcpy's output and OBS's input expectations.

ffmpeg - While optional, it helps with video format conversion when needed.

Installation and Setup

Installing Required Packages

Start by updating your system and installing the necessary tools:

sudo apt update
sudo apt install scrcpy v4l2loopback-dkms ffmpeg

Setting Up the Virtual Camera Device

Load the v4l2loopback kernel module to create your virtual webcam:

sudo modprobe v4l2loopback

To make this persistent across reboots, add it to your modules list:

echo "v4l2loopback" | sudo tee -a /etc/modules

Preparing Your Android Device

Enable USB debugging on your Android phone by following these steps:

Navigate to Settings → About Phone
Tap "Build Number" seven times to unlock Developer Options
Go to Developer Options and enable USB Debugging
Connect your phone via USB cable
Allow debugging access when prompted on your phone

Starting the Camera Stream

Launch scrcpy with virtual webcam output using this command:

scrcpy --v4l2-sink=/dev/video2

This redirects your phone's display (including camera apps) to the virtual webcam device at /dev/video2.

Configuring OBS Studio

In OBS Studio:

Click the "+" button in Sources
Select "Video Capture Device" or "Window Capture"
Name your source (e.g., "Android Camera")
Choose /dev/video2 as the device
Adjust resolution and frame rate settings as needed

If your video appears rotated, add the rotation parameter:

scrcpy --v4l2-sink=/dev/video2 --rotation=1

Troubleshooting Common Issues

Virtual Device Not Found

If /dev/video2 doesn't appear, verify the module loaded correctly:

ls /dev/video*

If missing, reload the v4l2loopback module:

sudo modprobe -r v4l2loopback && sudo modprobe v4l2loopback

Black Screen in OBS

Try limiting the resolution to improve compatibility:

scrcpy --v4l2-sink=/dev/video2 --max-size=1024

Make sure to restart OBS after launching scrcpy.

Phone Connection Issues

Check if your device is properly connected:

adb devices

If your phone isn't listed, reconnect the USB cable and re-enable USB debugging.

Streamlining Your Workflow

Create a simple script to avoid typing the full command each time:

nano ~/android_cam.sh

Add this content:

#!/bin/bash
scrcpy --v4l2-sink=/dev/video2 --max-size=1024

Make it executable:

chmod +x ~/android_cam.sh

Now you can start your Android webcam with:

~/android_cam.sh

Final Thoughts

This method provides a reliable, low-latency solution for using your Android phone as a webcam without relying on potentially unstable WiFi connections. The USB connection ensures consistent performance, making it ideal for important streams or recordings where reliability matters most.

The setup works with any camera app on your phone, giving you flexibility in how you want to frame and control your video feed. Just remember to keep your phone charged or use a longer USB cable that supports both data and charging if you plan on extended recording sessions.

Fix: Can't use zsh in vs-codium issue

Mohammed Chami — Sat, 14 Jun 2025 18:30:21 +0000

I recently run into an issue, I wanted to use zsh instead of sh or bash in the vs-codium terminal, I installed it as a flatpak.

Understand the problem:

The Flatpak app runs in an isolated sandbox;
It can't access your real shell (/usr/bin/zsh) directly.

Solution:

you need host-spawn to bridge between sandbox and host system.

How to Check if You're Using Flatpak

flatpak list | grep codium

If you see output like: com.vscodium.codium, you are using the Flatpak version

If You Are Using the Flatpak Version:
1- Install host-spawn:

sudo apt install flatpak-xdg-utils
flatpak override --user --filesystem=host com.vscodium.codium

2- Update your settings like (ctrl + shift + P, open user settings (json) ):

"terminal.integrated.defaultProfile.linux": "zsh",
"terminal.integrated.profiles.linux": {
  "zsh": {
    "path": "/app/bin/host-spawn",
    "args": ["zsh"],
    "icon": "terminal-bash",
    "overrideName": true
  }
}

Good luck :)

Fix Night Light Issue in Pop! OS

Mohammed Chami — Sat, 14 Jun 2025 18:14:56 +0000

I recently come across an issue that the night light in Pop! OS runs few seconds then get back to the bluelight even though it's ON and set to sunrise to sunrise, the easy solution that I found to install gammastep

Use gammastep:

sudo apt install gammastep
gammastep -O 3000  # Test (3000K = warm, higher value more bluelight)

to learn more about the features run:

gammastep -h

good luck :)

Export Avalonia App To linux Ubuntu step-by-step guide

Mohammed Chami — Fri, 13 Jun 2025 02:31:56 +0000

The first way needs dotnet runtime to run, the second way I will share the self contained without dotnet runtime.

Need: dotnet runtime

Step 1: Install System-Wide .NET SDK (Required)

Open a terminal and run:

# Add Microsoft's repository
wget https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb

# Install .NET 8 SDK
sudo apt update
sudo apt install -y dotnet-sdk-8.0

# Verify installation
dotnet --version

Step 2: Install dotnet-deb Tool

dotnet tool install --global dotnet-deb

Step 3: Prepare Your Avalonia Project

Open your .csproj file
Add these lines inside the <PropertyGroup> section:

<DebianPackage>true</DebianPackage>
<DebianPackageDependencies>libc6, libgcc1, libstdc++6</DebianPackageDependencies>
<RuntimeIdentifier>linux-x64</RuntimeIdentifier>

Step 4: Build the .deb Package

dotnet deb -c Release -r linux-x64

This will create a .deb file in:

/bin/Release/net8.0/linux-x64/[your-app-name].deb

Step 5: Install on Ubuntu

sudo apt install ./bin/Release/net8.0/linux-x64/[your-app-name].deb

Step 6: Run Your App

Find it in your application menu, or run via terminal:

[your-app-name]

Troubleshooting Tips

1- Missing dependencies? Run:

   sudo apt install libx11-dev libgbm-dev libgl1-mesa-dev

2- Not showing in app menu?

Check the generated .desktop file in:

/usr/share/applications/[your-app-name].desktop

3- Want a custom icon?

Add this to your .csproj:

   <DebianPackageIcon>path/to/your/icon.png</DebianPackageIcon>

4- You must install .NET to run this application.

export DOTNET_ROOT=/usr/share/dotnet/

Clean Uninstall Later

sudo apt remove [your-app-name]

note: Self contained:
To create a self-contained .deb package that doesn't require users to install .NET separately, follow these steps:

1. Modify Your `.csproj` File

Add these properties to ensure a self-contained deployment:

<PropertyGroup>
  <!-- Enable self-contained deployment -->
  <SelfContained>true</SelfContained>
  <PublishSingleFile>true</PublishSingleFile>
  <RuntimeIdentifier>linux-x64</RuntimeIdentifier>

  <!-- Required for dotnet-deb -->
  <DebianPackage>true</DebianPackage>
  <DebianPackageDependencies>libc6, libgcc1, libstdc++6</DebianPackageDependencies>
</PropertyGroup>

2. Publish & Build the .deb Package

Run this command to generate a standalone .deb:

dotnet publish -c Release -r linux-x64 --self-contained true
dotnet deb -c Release -r linux-x64

This will output a .deb file in:

bin/Release/net8.0/linux-x64/[your-app-name].deb

3. Key Improvements

No .NET Runtime Needed: The app bundles everything required.
Single Executable: PublishSingleFile reduces file clutter.
Debian Dependencies: Only basic system libs (libc6, etc.) are required.

4. Install & Test on Another Machine

sudo apt install ./your-app-name.deb
your-app-name

The app should run without requiring dotnet installation.

Troubleshooting

If you get library errors, ensure these are installed:

sudo apt install libx11-dev libgbm-dev libgl1-mesa-dev

Final notes

SelfContained=true bundles the .NET runtime inside your app.
PublishSingleFile merges DLLs into one executable.
The .deb package handles installation like any native app.

Thank you.

DEV Community: Mohammed Chami

How to Authenticate GitHub Using SSH and Push Code Securely

✅ Step 1: Check for Existing SSH Keys

🛠️ Step 2: Generate a New SSH Key

📋 Step 3: Add the SSH Key to the SSH Agent

🔑 Step 4: Add the Public Key to GitHub

🧪 Step 5: Test Your SSH Connection

🔁 Step 6: Change Git Remote from HTTPS to SSH

🚀 Step 7: Push Your Project

🔒 Security Best Practices

How to Check Disk Space in Linux (Terminal & GUI Methods)

1. Quick Terminal Commands

Check Total Disk Usage (df)

Check Folder Sizes (du)

Interactive Disk Usage Analyzer (ncdu)

2. Graphical Tools (For Desktop Users)

GNOME Disks (Default in GNOME)

KDE Partition Manager (For KDE Plasma)

File Manager (Thunar/Dolphin/Nautilus)

3. Advanced: Finding Large Files

Summary: Which Method Should You Use?

Understanding Rendering in Programming: From Code to Pixels

What Is Rendering, Really?

How Different Systems Handle Rendering

Web Browsers and WebViews

Native Mobile Apps

Cross-Platform Frameworks

The Performance Connection

Common Rendering Scenarios

Why This Matters for Developers

The Practical Takeaway

Understanding Hybrid Apps and WebViews: What Every Developer Should Know

What Are Hybrid Apps Really?

The WebView: Your App's Secret Browser

Platform Differences Matter

The Performance Reality Check

When Hybrid Apps Make Sense

The Development Experience

The Plugin Ecosystem

Common Pitfalls I've Encountered

The Future of Hybrid Development

Making the Right Choice

Final Thoughts

Understanding App Development Approaches: A Developer's Guide to Native, Cross-Platform, Hybrid, and PWA

Native App Development

When Native Makes Sense

The Native Trade-offs

Cross-Platform App Development

How the Magic Actually Works

The Performance Reality

The Developer Experience Difference

When Cross-Platform Shines

The Limitations to Consider

The Ecosystem Maturity

Making the Decision

Hybrid App Development

Understanding WebView

The Rendering Pipeline

Progressive Web Apps (PWA)

Service Workers: The Game Changer

The Installation Experience

Performance Considerations

Making the Right Choice

The Future Landscape

Conclusion

Checking Your .NET Installation (SDK and RunTime): A Quick Guide

The Quick Commands You Need

Checking Installed SDKs

Checking Installed Runtimes

The All-in-One Command

Understanding the Output

Common Scenarios

Starting a New Project

What If Nothing Is Installed?

Keeping Track of Versions

Final Thoughts

Connecting to Your Android Device via SSH from Linux: A Complete Termux Guide

Why SSH to Android?

Setting Up Termux for SSH Access

Installing and Configuring Termux

Check Total Disk Usage (`df`)

Check Folder Sizes (`du`)

Interactive Disk Usage Analyzer (`ncdu`)