Quick update for everyone: The Agentic Development course is now built out and available free inside the classroom. This is for anyone trying to use AI agents to build real software without turning every session into: - drift - rabbitholing - token burn - context loss - babysitting - "looks done" work with weak proof The short version: better prompts help, but they are not infrastructure. This course is about building the agentic infrastructure around your work: project memory, contracts, packetized work, testing guardrails, verification, handoffs, and human control. But there are other courses, some with similar ideas, so what makes this course worthwhile? Simple, this course also provides you with an Agentic Development Kit that will help program your agents so you can avoid the headaches above. Start here: https://www.skool.com/linux-infrastructure-academy-5525/classroom/722b11f9 It is free. If you go through Module 1, drop a comment with the failure mode you see most often in your own AI coding workflow.

Hi everyone, I just switched over to Zorin OS as my first stop into the linux ecosystem. I joined this community to get a better understanding of how the linux infrastructure works and to start developing my DevOps skills.

Quick follow-up to my last post about Agentic Development. A couple people asked what it actually means, so here is the simple version: This is for anyone trying to use AI agents to build real applications, but the agent keeps: - changing things you did not ask it to change - burning tokens fixing its own mess - forgetting context halfway through - giving confident answers with weak proof - going down a logical rabbit hole - making you babysit every response If you understand Linux/DevOps, the idea should feel familiar. We do not trust systems just because they look busy. We want logs, tests, boundaries, rollbacks, and proof. Agentic Development is that same mindset applied to AI-assisted building. The course structure I am working on looks like this: 1. Modules 1-3: diagnose the problem Why agents drift, why project memory breaks, and why systems need boundaries before agents touch them. 2. Modules 4-6: install the starter kit Testing guardrails, workflow proof, and a Plan/Contract/Packet framework for giving agents controlled work. 3. The rest of the course: use the agent setup Queues, handoffs, production readiness, team rails, portfolio proof, and scaling the practice. I'm still working on course material, so I am not opening the whole thing today. But I am thinking about making the first 3 modules free as an AI Agent Drift Audit. Quick question for everyone: Which problem have you run into the most with AI agents? Comment one: 1. Drift - it changes things you did not ask for 2. Token burn - you spend too much correcting bad output 3. Context loss - it forgets what matters 4. Rabbit holes - it follows a logical path away from the goal 5. Weak proof - it says done but you do not trust it 6. Babysitting - you have to keep steering every response If you have a real example, post it. I may use some of these examples to shape the first free challenge. Would the first 3 modules as a free audit be useful here?

Is anyone here interested in coursework related to Agentic Development?

The /etc/hosts file is a fundamental system file that plays a key role in how your Linux machine resolves domain names to IP addresses. It's essentially a local, manually managed DNS table. When you type a hostname like www.google.com into your browser, your system first checks /etc/hosts to see if there's a corresponding IP address listed there before sending a query to an external DNS server. This local check makes resolution extremely fast since no network communication is required. 🎯 Primary Uses * Blocking Websites: This is a common use for parents or system administrators. By mapping a domain to your local machine's loopback address (127.0.0.1), you can effectively prevent access to a site. For example, adding 127.0.0.1 twitter.com will block access to Twitter on your machine. * Local Development: Developers use the hosts file to test web applications before they go live on a public server. By adding an entry like 192.168.1.10 myapp.local, they can access their development server using a user-friendly hostname instead of an IP address. This mimics a live environment. * Network Shortcuts: You can create simple, memorable hostnames for devices on your local network. Instead of remembering 192.168.1.50 for your network printer, you could add 192.168.1.50 printer to your hosts file and simply type printer into your browser or command line to access it. ✍️ Editing the File The /etc/hosts file requires root permissions to edit. You can use a text editor like nano or vim with the sudo command. A good practice is to always back up the original file before making any changes. * Backup: sudo cp /etc/hosts /etc/hosts.bak * Edit: sudo nano /etc/hosts * Add your entries: Add new lines with the format IP_address hostname. * Save and Exit: Press Ctrl+O to save and Ctrl+X to exit in nano. After editing and saving, the changes take effect immediately without needing to restart any services. 🛡️ Important Notes * Comments: Lines starting with a # are ignored by the system and can be used to add comments for clarity. For example, # Blocked for security.