今日已更新 198 条资讯 | 累计 34832 条内容
关于我们

标签:#m

找到 10334 篇相关文章

AI 资讯

OCI Database Auto Backup Window Time Slots Reference

The Database resource in Oracle Cloud Infrastructure Database service provides an optional auto_backup_window option in its API during creation ( Terraform resource: oci_database_database ). The database resource can be used in an OCI Base DB system or Exadata Cloud VM Cluster pluggable database (PDB) for example. The time window enum value selected for initiating automatic backup for the database system is available in twelve two-hour UTC time windows as the following: Slot Description SLOT_ONE 12:00AM - 2:00AM UTC SLOT_TWO 2:00AM - 4:00AM UTC SLOT_THREE 4:00AM - 6:00AM UTC SLOT_FOUR 6:00AM - 8:00AM UTC SLOT_FIVE 8:00AM - 10:00AM UTC SLOT_SIX 10:00AM - 12:00PM UTC SLOT_SEVEN 12:00PM - 2:00PM UTC SLOT_EIGHT 2:00PM - 4:00PM UTC SLOT_NINE 4:00PM - 6:00PM UTC SLOT_TEN 6:00PM - 8:00PM UTC SLOT_ELEVEN 8:00PM - 10:00PM UTC SLOT_TWELVE 10:00PM - 12:00AM UTC Timezone used for the slots is always UTC regardless of the timezone used in the database. For example, if the user selects SLOT_TWO from the enum list, the automatic backup job will start in between 2:00 AM (inclusive) to 4:00 AM (exclusive) If no option is selected, a start time between 12:00 AM to 7:00 AM in the region of the database is automatically chosen. Reference Terraform resource: oci_database_database OCI API Reference: Database DbBackupConfig Safe harbor statement The information provided on this channel/article/story is solely intended for informational purposes and cannot be used as a part of any contractual agreement. The content does not guarantee the delivery of any material, code, or functionality, and should not be the sole basis for making purchasing decisions. The postings on this site are my own and do not necessarily reflect the views or work of Oracle or Mythics, LLC. This work is licensed under a Creative Commons Attribution 4.0 International License (CC-BY 4.0) .

2026-06-30 原文 →
AI 资讯

How to Stop LangChain Agents from Bankrupting Your API Budget

In November 2025, an engineering team deployed a market research pipeline using four LangChain agents. Due to a logic failure, the "Analyzer" and "Verifier" agents got stuck in a recursive ping-pong loop. Because every individual API call was perfectly valid, the system appeared healthy on their dashboards. 11 days later, they discovered a $47,000 API bill . This is the hidden cost of building autonomous AI: infinite hallucination loops . When an agent encounters an error or fails to reach a termination condition, it will ruthlessly retry, burning through tokens in milliseconds. Why Built-in Controls Fail If you build with LangChain or LangGraph, you are likely relying on two things for cost control: max_iterations : An application-layer limit. LangSmith : An observability dashboard. The problem with max_iterations is that it requires every developer to perfectly hardcode it into every agent. Furthermore, iterations do not equal cost, a single iteration with massive context bloat can still cost a fortune. The problem with LangSmith (and all observability tools) is that they act as a witness, not a circuit breaker. By the time your dashboard alerts you that a spike occurred, the money is already gone. To safely deploy agents to production, you need Agent Runtime Governance , a network-layer firewall that physically drops the HTTP request the exact millisecond a budget hits zero. Enter Loopers . What is Loopers? Loopers is an open-source, baremetal reverse proxy for AI agents. It sits on your critical path between LangChain and your LLM provider (OpenAI, Anthropic, etc.). It uses atomic Redis Lua scripts to reserve budget before the request is sent to the provider. If the agent exceeds its budget, Loopers fails closed and instantly severs the connection, guaranteeing zero budget leakage. Here is how to implement Loopers into your LangChain workflow in less than 5 minutes. Step 1: Spin up the Loopers Firewall Loopers is incredibly lightweight (~40MB RAM) and runs via D

2026-06-30 原文 →
AI 资讯

Enhance your CSS Reset with your Design System

If you're starting a web project, you're probably starting with a CSS reset, and for most of us, that means reaching for a trusted community solution - dropping it in and moving on. If you're building a design system, though, that habit may be working against you. The existing solutions The community reset ecosystem is genuinely good. Each tool approaches the browser compatibility problem from a slightly different angle. Some examples include: Eric Meyer's Reset is a classic: it zeros out margins, padding, and font sizes across every element, giving you a completely blank slate. It's minimal and predictable, which made it influential. Normalize.css smooths over inconsistencies while preserving the ones that are actually useful. sanitize.css and modern-normalize continue that evolution - incorporating contemporary best practices like box-sizing: border-box , improved form element handling, and accessibility-aware defaults. The problem isn't that any of these are bad. The problem is that they're all deliberately, necessarily generic. They can't know anything about your typeface, your color palette, your spacing scale, or how your interactive elements should behave. That's by design - they're tools for everyone, which means they're perfectly tailored for no one. The problem If you're building a design system, generic is exactly what you don't want your reset to be. The moment you drop in one of these resets and start building, you find yourself doing a second round of work. You apply your typeface to body . You reset margins on headings. You make form elements inherit fonts. You define focus styles. You're re-resetting - applying your design language on top of a layer that just cleared out the browser's defaults and replaced them with... more defaults you'll override. Worse, that duplication doesn't stay in one place. Every component you build either re-declares these foundational styles or silently assumes they're already set upstream. You end up with either redundanc

2026-06-30 原文 →
AI 资讯

Prioritizing Abstractions Over Complexity: Addressing Illusions in Distributed Systems Platform Design

Introduction In the world of distributed systems, complexity is the beast we’re all trying to tame. Teams building platforms often fall into the trap of believing that hiding this complexity is the ultimate goal. The logic seems sound: if users don’t see the mess, they won’t be burdened by it. But this approach, while well-intentioned, often leads to the creation of illusions —systems that appear simple on the surface but are brittle and unpredictable beneath. These illusions don’t just fail to solve the problem; they exacerbate it, leading to increased cognitive load, unexpected failures, and long-term maintenance nightmares. Consider a platform designed to abstract away the intricacies of distributed transactions. If the abstraction merely masks the complexity without addressing its root causes—such as inconsistent network latencies or partial failures—users will eventually encounter edge cases where the system behaves unpredictably. For example, a transaction might appear to succeed but fail silently due to a race condition in the underlying distributed lock mechanism. The illusion of simplicity breaks down when the system’s internal state deforms under pressure, leading to data inconsistencies or service outages. The core issue lies in the misunderstanding of abstractions . A meaningful abstraction doesn’t just hide complexity; it transforms it into a more manageable form. It exposes the essential properties of the system while encapsulating the non-essential details. In contrast, an illusion merely obscures the complexity, leaving it to fester beneath the surface. For instance, an abstraction might provide a consistent API for distributed state management, while internally handling retries, idempotency, and conflict resolution. An illusion, on the other hand, might simply wrap a flaky distributed database in a prettier interface, without addressing the underlying issues of consistency or availability. The pressure to deliver platforms quickly often exacerbates

2026-06-30 原文 →