DEV Community: abhimanyu sharma

PhantomShell AI — The Ghost in Your Machine

abhimanyu sharma — Mon, 26 Oct 2026 21:53:55 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What if your Linux terminal had a ghost living inside it—not to haunt your computer, but to help you understand it?

PhantomShell AI is a local AI-powered Linux command-line assistant that explains shell commands, identifies selected potentially dangerous command patterns, and brings a spooky personality to everyday terminal interactions.

Built with Python, Ollama, and an open-weight AI model, this project explores what happens when local AI meets Linux, developer productivity, and the mysterious idea of a Ghost in the Machine.

What I Built

PhantomShell AI is designed to help Linux beginners, developers, and DevOps learners understand commands before using them.

Instead of blindly copying commands from tutorials or the internet, users can ask the assistant what a command does and receive an AI-generated explanation.

✨ Key Features

👻 Haunted Terminal: A spooky command-line assistant with a ghost-inspired personality.
🧠 Local AI Brain: Uses an open-weight language model through Ollama to explain Linux commands.
🛡️ Ghostly Security Guard: Checks commands against selected patterns associated with potentially dangerous operations.
🔒 Privacy-Focused: Sends AI prompts to a locally running model rather than a hosted AI API.
🌐 Offline Potential: Supports local inference without an internet connection once the model and required dependencies have been downloaded.
⚡ Rules-Only Mode: Checks commands without requiring an AI model.
🐧 Linux and DevOps Learning: Helps users understand shell commands and their potential consequences.

Why I Chose This Idea

The theme Ghost in the Machine made me think about an invisible intelligence living inside a computer—something that can observe, explain, and warn without taking control away from its user.

I wanted to turn that idea into a practical developer tool.

PhantomShell AI combines the mysterious atmosphere of a haunted terminal with a real use case: helping people understand Linux commands and recognize potentially risky operations.

Safety first: PhantomShell AI analyzes command text and does not execute shell commands. Its rule-based checks are limited, and the absence of a warning does not mean a command is safe.

🖼️ Project Poster

The poster captures the project's vision: a mysterious AI presence inside a Linux terminal, powered by local AI and open-source technology.

Try It Locally

Clone the repository:

git clone https://github.com/360abhimanyu/PhantomShell-AI.git
cd PhantomShell-AI

Install the required system tools on Ubuntu:

sudo apt update
sudo apt install -y python3 python3-pip python3-venv

Create and activate a Python virtual environment:

python3 -m venv .venv
source .venv/bin/activate

Install Python dependencies:

pip install -r requirements.txt

For AI-powered explanations, install Ollama by following its official Linux installation instructions, then download the model:

ollama pull qwen2.5:3b

Start Ollama if it is not already running:

ollama serve

Open another terminal, activate your virtual environment, and run:

python3 phantomshell.py

You can also try individual commands:

# Explain a Docker command
python3 phantomshell.py "docker ps -a"

# Check a potentially dangerous command
python3 phantomshell.py "sudo rm -rf /"

# Analyze a command without using the AI model
python3 phantomshell.py --rules-only "git reset --hard"

Run the unit tests:

python3 -m unittest discover -s tests -v

For the latest setup instructions and any project-specific requirements, see the repository README.

Note: The commands above assume the repository contains the documented files and CLI options. A live hosted demo or recorded video is not currently linked.

Code

🚀 GitHub Repository:

https://github.com/360abhimanyu/PhantomShell-AI

Explore the source code, run the project locally, report issues, and contribute improvements.

The project includes the following components:

phantomshell.py — Main Python command-line application.
README.md — Project documentation and setup instructions.
requirements.txt — Python dependencies.
tests/test_phantomshell.py — Unit tests for command-warning rules.
LICENSE — Project license.

Contributions are welcome! You can help improve command detection, add test cases, refine explanations, enhance documentation, and make the project more useful for Linux and DevOps learners.

If you find the project interesting, ⭐ star the repository and share your feedback.

How I Built It

I built PhantomShell AI using Python, local AI inference, and rule-based command analysis.

Technology Stack

Python: Implements the core application and CLI.
Ollama: Runs the language model locally.
Qwen 2.5 3B: An open-weight language model used for command explanations.
Regular expressions: Detect selected command patterns that may indicate risky operations.
Unit testing: Checks that warning rules behave as expected.
Git and GitHub: Support version control and open-source collaboration.

How It Works

Input: The user supplies a Linux shell command.
Analysis: PhantomShell AI checks the command text against selected safety patterns.
Warning: If a recognized risky pattern is found, the assistant displays a warning.
AI explanation: When local AI is enabled, the command text is sent to the locally running model for explanation.
Output: The assistant presents its explanation and any applicable warnings in the terminal.

The AI model provides explanations, while the rule-based scanner provides an additional layer of warnings. These mechanisms are not a complete security solution, and the application does not execute the supplied command.

Why Local AI?

Local inference gives users more control over where their prompts are processed. It also allows experimentation without depending on a paid, hosted AI API for every request.

After the model and dependencies are downloaded, the core AI workflow can operate without an internet connection, provided the local environment is configured correctly.

Why Does Open Innovation Matter?

Open innovation matters because useful AI tools should be accessible, inspectable, and improvable by the communities that use them.

PhantomShell AI uses an open-weight model and local inference to give developers an alternative to relying entirely on closed AI APIs.

This approach makes several things possible:

More control: Users can run compatible models on their own machines.
Privacy-conscious development: Prompts can remain within the local environment when local inference is used.
Experimentation: Developers can explore different compatible models and improve the assistant's behavior.
Community collaboration: Contributors can improve warning rules, add tests, refine documentation, and suggest new features.
Accessible learning: Beginners can explore Linux commands with an AI assistant without requiring a hosted AI subscription.

Open-weight models do not automatically mean unrestricted open-source software; model licenses and dependencies still matter. However, combining local inference with an open-source application gives developers meaningful opportunities to inspect, adapt, and extend their tools.

For me, open innovation means building AI that people can explore, understand, and improve together.

The goal is not simply to build another chatbot. It is to create a useful, community-driven tool that helps developers learn while keeping control of their systems.

My Agent Session

I developed PhantomShell AI through an iterative workflow that included designing the command-line experience, implementing rule-based warnings, connecting local AI inference, and testing command-analysis behavior.

I have not included a DevRelay session link because I do not have a recorded session URL to share.

If I publish a recorded agent session, I will add the link here so others can follow the development process and understand the decisions behind the project.

The Spirit of It

Imagine opening your terminal late at night.

You type a command. Before you run it, a mysterious presence responds:

“I see what you're trying to do. But are you sure you know what this command will leave behind?”

That is the spirit of PhantomShell AI.

The ghost isn't there to control your machine. It's there to help you understand it.

Behind the spooky interface is a practical idea: developers deserve tools that help them learn, make informed decisions, and retain control over their own systems.

The real magic is not the ghost itself. It is the combination of local AI, open technology, and a community that can improve the software together.

Because even ghosts believe in open source. 👻

Prize Categories

PhantomShell AI is built around the challenge's open-source AI theme, with a focus on open-weight models, local inference, and community-driven development.

I will select the applicable partner prize categories after checking the official Week 4 challenge page and each category's eligibility requirements.

Built with 👻, 🐍, and open-source AI for Hacktoberfest 2026.

Explore the project: https://github.com/360abhimanyu/PhantomShell-AI

Thanks for reading, and happy Hacktoberfest!

SlothOps AI: Your Local AI Automation Assistant

abhimanyu sharma — Mon, 19 Oct 2026 21:57:14 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

SlothOps AI is an open-source, AI-powered DevOps log analyzer designed to help developers troubleshoot application and infrastructure issues with less manual effort.

When an application crashes, a Docker container fails, or a Kubernetes pod enters CrashLoopBackOff, developers often spend valuable time searching through lengthy log files to identify the root cause.

SlothOps AI simplifies this process by allowing users to analyze logs through a web dashboard and receive AI-generated explanations, possible root causes, and troubleshooting suggestions.

Key Features

🔍 Automated Log Analysis: Identify common errors, warnings, and failure patterns.
🤖 Local AI Inference: Use Ollama and an open-weight language model to analyze logs locally.
🛠️ AI-Powered Troubleshooting: Get explanations and potential fixes for detected issues.
🐳 Docker Support: Run the application in a containerized environment.
☸️ DevOps Log Support: Test with application, Docker, Kubernetes, and Linux logs.
🔒 Local-First Approach: Keep logs on your machine when using the local configuration.

The main goal is to reduce repetitive troubleshooting work so developers can spend less time reading logs and more time building and deploying applications.

Demo

Project Screenshot

Run It Locally

Prerequisites: Python, Ollama, and Git.

1. Clone the repository

git clone https://github.com/360abhimanyu/Project-SlothOps-AI-Your-Local-AI-Automation-Assistant.git
cd Project-SlothOps-AI-Your-Local-AI-Automation-Assistant

2. Download the AI model

ollama pull llama3.2:3b

3. Install dependencies

pip install -r requirements.txt

4. Start the application

python app.py

5. Open the dashboard

Visit http://127.0.0.1:5000 in your browser and upload a log file to test the analyzer.

A public demo or video walkthrough can be added here when available.

Code

🚀 GitHub Repository: SlothOps AI — Your Local AI Automation Assistant

The repository contains the application source code, Flask backend, web dashboard, AI integration, Docker configuration, documentation, and testing resources.

Feel free to explore the code, report issues, suggest features, or contribute improvements.

⭐ If you find this project useful, consider starring the repository!

How I Built It

I built SlothOps AI using open-source technologies and a local-first AI architecture.

Technology Stack

Python: Core application logic.
Flask: Backend web framework.
HTML, CSS, and JavaScript: Interactive web dashboard.
Ollama: Runs the language model locally.
Llama 3.2 (3B): Open-weight language model for AI-assisted log analysis.
Docker: Containerization and deployment.
Pytest: Automated testing.

How It Works

Upload logs: The user submits a log file through the dashboard.
Detect errors: The application scans for recognizable error and warning patterns.
Analyze with AI: Relevant log information is processed by the locally running language model.
Generate insights: The model provides a summary, potential causes, and troubleshooting recommendations.
Review solutions: The developer reviews the results and decides on the appropriate corrective action.

The idea is to turn repetitive log investigation into a simpler workflow with AI as a troubleshooting assistant.

Why Does Open Innovation Matter?

Open innovation makes AI development more accessible, transparent, and collaborative.

By building SlothOps AI with open-source frameworks and an open-weight model, I wanted to demonstrate that useful AI-powered developer tools do not have to depend entirely on proprietary AI APIs.

What Open Innovation Makes Possible

Accessibility: Developers can experiment with local AI without requiring a paid, proprietary AI API.
Privacy-conscious development: Logs can remain on the local machine when the application and model are configured for local-only processing.
Flexibility: Users can experiment with supported models and adapt the application to their needs.
Community contributions: Developers can add parsers, improve error detection, fix bugs, and introduce new features.
Learning opportunities: The project brings together AI, Python, Docker, and practical DevOps troubleshooting.

Open innovation gives developers the freedom to inspect, modify, learn from, and build upon existing technology. That is what makes community-driven AI projects valuable.

My Agent Session

SlothOps AI was developed around the idea of using AI to simplify repetitive DevOps tasks.

A DevRelay agent session or development walkthrough can be linked here if available.

Agent session link: Not added yet.

The Lazy Payoff

The biggest benefit of SlothOps AI is reducing the repetitive effort involved in investigating logs.

Without an analyzer, developers may need to search through thousands of log lines, identify relevant errors, connect related events, and research possible fixes.

SlothOps AI helps streamline this process by identifying common error patterns and generating AI-assisted explanations and troubleshooting suggestions.

The actual time saved depends on the size of the logs, model performance, and the complexity of the issue. I have not yet measured a reliable time-saving benchmark, so I won't claim a specific percentage.

The long-term vision is simple: less time searching through logs, less repetitive troubleshooting, and more time building useful things.

That is the SlothOps philosophy: automate the repetitive work and let developers focus on what matters.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady

Additional partner categories can be included if the project meets their eligibility requirements.

Final Thoughts

Building SlothOps AI was an opportunity to explore how open-weight AI models can support real-world DevOps workflows.

This project is a step toward making AI-powered troubleshooting more accessible to developers who want to experiment, learn, and build with open-source technology.

If you are interested in AI, DevOps, Docker, or open source, check out the project and feel free to contribute!

🦥 Let's make DevOps troubleshooting a little lazier, one log file at a time.

GitHub: https://github.com/360abhimanyu/Project-SlothOps-AI-Your-Local-AI-Automation-Assistant

Hacktoberfest #OpenSource #AI #DevOps #Python #Docker #Ollama #LLM

AI DevOps Log Analyzer: Turning Application Logs into Actionable Insights with Open-Source AI

abhimanyu sharma — Tue, 13 Oct 2026 01:17:16 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

I built an AI DevOps Log Analyzer, a local-first AI-powered application that helps DevOps engineers and small IT teams understand application errors, investigate infrastructure issues, and identify potential root causes without manually reading thousands of lines of logs.

Troubleshooting production issues can be time-consuming. Whether an application runs on Linux, Docker, or Kubernetes, its logs often contain connection failures, timeouts, readiness probe errors, and other messages that require technical expertise to interpret.

My project aims to make this process faster and easier by using an open-weight language model to analyze logs and generate structured troubleshooting reports.

Key Features

Log Upload and Analysis: Upload .log and .txt files or paste log content directly into the application.
AI-Powered Troubleshooting: Analyze errors, warnings, exceptions, connection failures, and timeouts.
Potential Root Cause Identification: Generate ranked hypotheses based on the available log evidence.
Actionable Recommendations: Suggest diagnostic commands and troubleshooting steps for investigating issues.
Secret Redaction: Apply basic redaction patterns to help remove common credentials and sensitive information before analysis.
Downloadable Reports: Export the generated analysis as a Markdown report for incident documentation and team collaboration.
Local AI Inference: Run the model locally through Ollama instead of depending on a paid proprietary model API.

Who Would Pay for It?

My initial target users are:

Freelance DevOps engineers managing multiple client environments.
Small businesses without dedicated site reliability engineering teams.
Startups running applications in Docker or Kubernetes.
Cloud consultants who regularly investigate application failures.
Junior DevOps engineers who need help understanding unfamiliar errors.

The business opportunity is to reduce the time spent investigating routine incidents and make troubleshooting knowledge more accessible.

My initial monetization hypothesis is a free local version and a paid version with advanced analysis, reusable incident reports, team workflows, and additional log integrations. I would validate willingness to pay with real users before committing to a pricing model.

Demo

The application uses a simple Streamlit interface where users can upload logs, run the analysis, inspect the generated report, and download the results.

Local demo instructions:

Start Ollama and ensure the selected model is installed.
Run the Streamlit application.
Upload the included sample_logs.txt file.
Click Analyze logs.
Review the summary, likely causes, supporting evidence, and recommended checks.
Download the resulting report.

The application runs locally at http://localhost:8501 by default.

Live deployment: Not yet available. The current version is designed for local execution.

Code

GitHub repository: https://github.com/360abhimanyu/AI-DevOps-Log-Analyzer.git

The project contains the following files:

ai-devops-log-analyzer/
├── app.py
├── log_analyzer.py
├── requirements.txt
├── sample_logs.txt
├── Dockerfile
├── .gitignore
└── README.md

Core Technology Stack

Python: Application logic and log processing.
Streamlit: Interactive web interface.
Ollama: Local model runtime and inference API.
Qwen2.5 3B: Initial open-weight model choice.
Docker: Containerization support.
Git and GitHub: Version control and project hosting.

Example Input

2026-10-13T10:15:01Z ERROR Database connection failed: connection refused
2026-10-13T10:15:02Z ERROR Connection timeout after 30 seconds
2026-10-13T10:15:03Z WARN Retrying database connection (attempt 2)
2026-10-13T10:15:04Z ERROR payment-api: readiness probe failed

Expected Analysis

The model can identify a database connectivity problem as a likely issue and suggest investigating:

Whether the database service is running.
Whether the application can reach the database host and port.
Whether firewall rules or network policies are blocking connectivity.
Whether the database has reached its connection limit.
Whether the readiness probe configuration matches the application's actual health endpoint.

These are diagnostic hypotheses, not guaranteed root causes. The actual diagnosis must be validated against the environment and supporting evidence.

How I Built It

I built the initial version around a straightforward principle: use traditional code for predictable log processing and open-source AI for interpreting context and generating explanations.

1. Local AI with Ollama

I selected Ollama as the local model runtime and Qwen2.5 3B as the initial model.

The model can run on a suitably configured personal computer, depending on available memory, hardware, and inference performance. This avoids the need for a paid proprietary AI API for the core analysis workflow.

2. Python Log Processing

The Python analysis module handles input preparation before sending logs to the local model.

It includes basic secret-redaction patterns, extracts lines that appear to contain errors or warnings, and limits the amount of text sent for analysis.

This preprocessing is important because raw infrastructure logs can be noisy, repetitive, and unnecessarily large.

3. Streamlit User Interface

I used Streamlit to create a simple interface for uploading files, pasting log content, configuring the model name, viewing the report, and downloading the analysis.

This allowed me to focus on the usefulness of the analysis rather than spending time building a separate frontend.

4. Structured AI Analysis

The model receives a prompt that asks it to organize the report into sections:

Summary.
Important evidence.
Likely causes, ranked by plausibility.
Recommended diagnostic checks.
Potential fixes.
Confidence and missing information.

The prompt also instructs the model to distinguish evidence from hypotheses and to avoid recommending destructive commands.

5. Containerization and Reproducibility

I included a Dockerfile and dependency list to make the application easier to package and reproduce.

The next engineering steps are to add automated tests, strengthen secret detection, evaluate model accuracy on representative logs, and build a CI workflow with GitHub Actions.

Why Does Open Innovation Matter?

Open innovation is central to this project because the objective is not simply to call an AI API. It is to build a useful troubleshooting tool whose core analysis can run using an open-weight model under the user's control.

Privacy and Control

Infrastructure logs can contain internal service names, customer identifiers, request details, and occasionally credentials.

Local inference makes it possible to analyze logs without sending their contents to an external model provider. This benefit depends on keeping the application, model runtime, and surrounding infrastructure configured appropriately.

The current redaction implementation is best-effort and does not guarantee that all sensitive information will be removed.

Lower Marginal Inference Costs

A commercial model API may charge for each request or token processed. With a locally hosted model, there is no per-request charge from a proprietary model API for local inference.

Hardware, electricity, maintenance, and hosting still have costs, so local inference is not automatically free. However, predictable infrastructure costs can make repeated analysis more economical for some users.

Model Flexibility

Open-weight models let developers experiment with different models and compare their performance on their own workloads.

For example, I can evaluate whether a different model better understands Kubernetes events, Linux service failures, or application stack traces without redesigning the entire interface.

I can also explore domain-specific evaluation datasets, prompt improvements, and fine-tuning where the model license and available resources permit it.

Reduced Vendor Lock-In

The application communicates with a local model runtime rather than relying on a single proprietary AI provider. This creates room to change the underlying model as requirements, performance, and hardware constraints evolve.

Where the Open Approach Helps

For this project, the biggest advantage is control over the analysis environment. A small team can experiment with AI-assisted troubleshooting while retaining greater control over where its logs are processed.

I have not yet established through a controlled benchmark that this implementation outperforms a closed API in accuracy or speed. That comparison would be a useful next step: test both approaches on the same sanitized log dataset and compare diagnostic accuracy, latency, cost, and data-handling requirements.

What's Next?

I want to extend the project beyond the initial MVP.

My planned improvements include:

Kubernetes event and kubectl logs analysis.
Docker container failure analysis.
Support for larger log files and multiple log formats.
Improved redaction and configurable retention controls.
Searchable incident history and downloadable reports.
Automated testing and continuous integration with GitHub Actions.
Evaluation against a curated dataset of known infrastructure failures.
A more advanced version for teams that need shared incident workflows.

The long-term goal is to make routine infrastructure troubleshooting faster and more approachable, especially for teams that cannot afford expensive observability platforms or dedicated SRE resources.

My Agent Session

Optional: Add a DevRelay session link or embed here if you record and save an eligible agent session.

My First User

I have not yet collected verified feedback from a real user or received payment for this project.

My next step is to ask a DevOps engineer or a small IT team to test the tool using sanitized logs from a real troubleshooting scenario.

I want to understand whether the report actually saves time, whether the recommended checks are useful, and what functionality would make the tool valuable enough to pay for.

I will document the feedback honestly, including problems discovered during testing.

Prize Categories

Primary fit: Open-Source AI / Side Hustle, as described in the challenge.

I will add any applicable partner-specific prize categories after verifying their eligibility requirements on the official challenge page.

Built with Python, Streamlit, Ollama, and an open-weight language model.

My goal is to explore how open-source AI can turn a repetitive DevOps task into a practical tool that gives engineers more time to focus on solving problems rather than searching through logs.

AI Garden Buddy: A Local AI That Helps You Touch Grass

abhimanyu sharma — Mon, 05 Oct 2026 23:03:54 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I built AI Garden Buddy, a simple gardening assistant designed to help people spend less time on screens and more time outside.

The idea is simple: instead of using AI just to answer questions, I wanted AI to give people a reason to step away from the computer and actually do something outdoors.

AI Garden Buddy helps users create a simple gardening plan based on their location, season, available sunlight, garden space, and experience level.

It can suggest:

Plants that may be suitable for the user's garden
Weekly gardening activities
Watering and care suggestions
Simple outdoor gardening missions

A practical plan that the user can take outside

For example, instead of spending 30 minutes chatting with an AI about gardening, the application can give you a task like:

"Spend 20 minutes outside today. Prepare a small area for planting and check the soil moisture."

The goal is to make the screen the starting point, not the destination.

Live Demo:

Code

GitHub Repository: https://github.com/360abhimanyu/AI-Garden-Buddy

The project is intentionally kept simple so that other developers can understand it, run it locally, and experiment with the AI component.

How I Built It

I built AI Garden Buddy using a lightweight web application with a local AI model.

The main open-weight AI model I used is Qwen2.5 1.5B, running locally through Ollama.

The basic flow looks like this:

The application sends the gardening information to the locally running model, which generates recommendations and outdoor activities.

The important part is that the AI doesn't need to be a large cloud service to be useful. A small open-weight model can handle the core experience while running on the user's own machine.

I also added a fallback experience so that the application can still provide useful gardening suggestions when the local model isn't available.

Why Does Open Innovation Matter?

Open innovation matters because it gives developers more control over how AI is used.

For this project, I wanted to avoid making another application that depends completely on a closed AI API.

Using an open-weight model and local inference means the project can be experimented with without sending every gardening request to a third-party AI service.

It also makes the architecture easier to change.

I can experiment with different models, change the prompts, modify the application logic, or eventually fine-tune the model for gardening-related tasks.

There is also an important privacy benefit. A user can run the AI locally instead of sending their information to a remote AI service.

For me, the biggest benefit is experimentation.

OpenAI makes it possible to take an idea, run it locally, understand how the pieces work, and change them without being locked into one provider.
My Agent Session

I used AI-assisted development to build this project and experimented with the application's structure, user experience, and open-source AI integration.

Agent Session: I used AI-assisted development to help design and build AI Garden Buddy, including the application structure, user experience, and integration with the local open-weight AI model.

I did not use a DevRelay session for this project, so there is no session link to share.

Prize Categories

Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Final Thought

AI doesn't always have to keep us in front of a screen.

Sometimes the best AI experience is one that gives you a useful answer and then tells you to close the laptop.

That's what I wanted to build with AI Garden Buddy.

Get the gardening plan.

Go outside.

Touch grass.

Linux Buddy: A Linux Learning Buddy for Students 🐧

abhimanyu sharma — Sun, 04 Oct 2026 09:32:14 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built Linux Buddy, a simple learning assistant for students who are starting with Linux.

While working on Linux learning content, I noticed that students often remember individual commands but struggle to solve real problems.

For example, they may know commands such as ls, chmod, or ssh, but when something goes wrong, they often don't know what to check first or which command to use.

I wanted to build something that could help with that.

Linux Buddy focuses on four areas:

Learning Linux concepts
Troubleshooting Linux problems
Practicing through labs
Preparing for Linux interviews

The main idea behind the project is:

Don't just learn Linux commands. Learn how to troubleshoot Linux.

Demo

The live website is available here:

https://360abhimanyu.github.io/Linux-Buddy/

I also recorded a short demo of the project:

https://youtu.be/ha1V5oEgcvQ

Code

The project is built using HTML, CSS, and JavaScript.

GitHub repository:

https://github.com/360abhimanyu/Linux-Buddy

I kept the project structure simple, so it is easy to understand and extend.

How I Built It

I started with a simple question:

How can I make Linux learning more practical for beginners?

Student --> Linux Buddy --> Understand the Problem --> Choose the right command --> Understand the output --> Take the next step

The website offers various ways for students to interact with Linux Buddy, including learning concepts, troubleshooting issues, practicing labs, and preparing for interviews.

For the AI part, I used Google's open-weight Gemma model. I chose Gemma because it offers an open model I can use and experiment with for focused Linux learning and troubleshooting.

The goal of the AI is not simply to provide a command as an answer. It should help explain what the command does, why it is being used, and what the student should check next.

For example, if someone asks:

My Nginx website is not working.

The idea is to guide them through the troubleshooting process rather than simply giving them one command.

Why Does Open Innovation Matter?

Open innovation gives developers more freedom to experiment and build solutions for specific problems.

For Linux Buddy, open-source and open-weight AI makes it possible to explore how AI can be used specifically for Linux learning and troubleshooting.

It also makes the project easier to customize and improve over time.

For me, the important part is that the student should not only get an answer. They should understand how to approach the problem and learn something from the process.

My Agent Session

I will add my DevRelay agent session here if applicable.

Prize Categories

I am submitting Linux Buddy for the overall Hacktoberfest Weekend Challenge.

I will also enter the Best Use of Gemma category if the final version uses Google's open-weight Gemma model.

Final Thoughts

Linux Buddy started with a simple idea.

Students don't just need a list of Linux commands. They need help understanding how to use those commands when something doesn't work.

I wanted to build a small project around that idea and make Linux learning a little more practical and approachable.

This is the first version, and there are still many things I would like to improve, including more troubleshooting scenarios, hands-on labs, progress tracking, and a stronger AI-powered learning experience.

Thanks for checking out Linux Buddy and the Hacktoberfest Weekend Challenge.