标签：#RAM

submitted by /u/iximiuz [link] [留言]

With all the hype in the past several years around AI (or more specifically GenAI), I'm not afraid to say – I'm an AI skeptic. It doesn't mean that I don't believe that some day AI may have a huge impact on human beings' lives, but at the moment, all I can see is irrational hype. In my background, I came from infra-security; I am not a developer, nor do I consider myself an AI expert. I am a cloud architect, meaning I'm looking at proposed architectures, seeing how they suit business requirements, and whether they are deployed in a secure, resilient, and perhaps cost-effective way. I don't see value in adding AI to every design, just for the sake of saying "our application now includes AI". I've been watching the industry since 2023 go nuts. Suddenly, everyone is eager to add AI capabilities, chasing some unexplained FOMO before the machines replace our jobs. I'm not against the use of AI. As a matter of fact, I've been using Grammarly for many years (since, for most of us, English is not our first language). In the past several years, I've been using chatbots such as ChatGPT, Perplexity, and recently Gemini daily, asking questions about various topics and aspects of my life. From asking the bot to provide me an answer about a specific character in a favorite TV show, to "how do I resolve an alert shown on my car's dashboard," and up to "summarize this blog post for my newsletter". It's great that I can ask Gemini to create me a LinkedIn post based on an article I just read, add some emojis and hashtags, and at the end create me a cover image for the post. For a probabilistic system, this is great. I am expecting the system to be creative and produce me attractive results, sometimes even funny images. For a home consumer, this is great, but far from been ground breaking technology. I truly believe that the "big money" will come from enterprises paying a lot of money for AI-based solutions, once the industry can actually make something good from a non-deterministic s

When Claude Opus 5 and GPT-5.6 arrived, I expected my coding agents to become noticeably better. Instead, some of my workflows felt worse. The agents seemed more eager, less predictable, and occasionally “dumber” than before. Naturally, I blamed the new models. Very scientific of me. Maybe it was a skill issue Then I watched Andrej Karpathy’s interview on the No Priors podcast. One idea stuck with me: when an agent fails, the capability may already exist. The problem could be how we instruct it, what memory we provide, or how we arrange the workflow. That made me question something I had mostly ignored: Were my custom skills still compatible with the newer models? I gave my agent this prompt: Can you audit our custom skills against the current models? Flag stale prompts, conflicting instructions, outdated assumptions, and anything that should be simplified or removed. Then test each skill on a representative task and propose the smallest updates needed. The audit found instructions written around the behavior of older models. Some were redundant. Some were no longer necessary. Others pushed the newer models too hard and caused them to overdo tasks. After cleaning those up and testing the skills again, the results felt noticeably better. The official guidance supports this This was not proof that every disappointing result is caused by an outdated prompt. Models can still regress, behave inconsistently, or introduce genuine breaking changes. But both Anthropic and OpenAI recommend recalibrating instructions during model migrations. Anthropic’s Claude Opus 5 documentation says the model now verifies its work without being told. It specifically recommends removing verification instructions carried over from earlier models because they can cause over-verification. OpenAI’s GPT-5.6 guidance recommends removing repeated instructions, simplifying tool descriptions, and running the same evaluations after each change. In OpenAI’s internal coding-agent evaluations, leaner sys

submitted by /u/Nuoji [link] [留言]

Let's get something out of the way first. Having data is good. Having a database full of reviews, commits, and org activity sitting there quietly, untouched, unread, never once glanced at by a human being with a coffee and an opinion? That's not "having data." That's a very expensive data graveyard. At LiveReview , we build what we call a Blast-Radius Aware AI Code Review for Business-Critical Systems . Which is a fancy way of saying: we review your code, we figure out how bad it would be if a change goes wrong, and we don't shut up about it until someone fixes it. Along the way we accumulate a review data: who reviewed, how much, how fast, how often, which repos are on fire. And for a while, that pile just sat there. Engineering leaders would ask "is adoption increasing?" and get back a vibe, not an answer. So we built Livi , a chat bot that answers real questions about that data with real charts, not paragraphs of hedging. This post technically about how Livi draws those charts. Specifically: why we never let the LLM touch a pixel, how the same chart definition ends up as both a live interactive graph in your browser and a flat PNG in a Slack thread, and why teaching a language model to pick the right chart shape is a surprisingly deep rabbit hole. The core decision: don't ask the LLM to draw, ask it to describe The tempting, wrong idea is: "let's have the LLM generate an image." Please don't. Image-generating models are a different beast entirely, and even if you got one to draw a bar chart, you'd have no way to verify the numbers on it are real. You'd be trusting a model that hallucinates plausible-sounding review counts to also render them faithfully into pixels. That's not a chart, that's chart-shaped fan fiction. The actually good idea, and the one every serious LLM-charting integration eventually converges on, is: the LLM writes Vega-Lite , a JSON grammar for describing charts declaratively. You don't say "draw a blue bar going up." You say: { "mark" : "bar"

submitted by /u/wordbit12 [link] [留言]

Nobody likes popovers, everyone makes them anyway. This makes them a Tolstoy kind of thing -- there are a handful of tricks that make them better, and an infinite number of ways to mess up. submitted by /u/Odd-Tell9763 [link] [留言]

When many people are first learning how to code, they find it difficult and when they ask, "How can I get better at coding?" they are usually told, "With time and practise it will get easier." . But instead of using so much time and effort to get better at coding using hard programming languages, what if coding could get better for you instead of you getting better at coding ? Well, this is the reason that inspired me to make a new programming language called Sofya . Sofya is designed to be so simple (even simpler than Python ) so that anyone can find programming easy and fun. But to prove my point, let us use an example. Let us say that we want to make a program that will show us all the numbers from 1 to 20 . Let us compare how this program will look like in Python and Sofya . The Python Program for number in range ( 1 , 21 ): print ( number ) The Sofya Program Variable Number is 0 Do this { Increase Variable[Number] by 1 Write Variable[Number] on the screen } Until Variable[Number] = 20 From this example, we can see that the Sofya program is easier than the Python program, for a beginner in programming, for the following reasons: Sofya uses simpler commands than Python: It is easier for a beginner in programming to remember the command Do this...Until Variable[Number] = 20 , which is used for making a loop, as compared to the command for number in range(1, 21): . Sofya's syntax is closer to English as compared to Python's syntax: When we are making a loop variable in Sofya, we simply say Variable Number is 0 rather than saying number in range(1, 21) in Python. The Sofya program can easily be understood by anyone even if it is the first time that they are seeing it as compared to Python: A beginner in programming can easily tell that in the line where we say Increase Variable[Number] by 1 , that we are increasing the value of the variable called 'Number' by 1 as compared to the line number in range(1, 21) in Python. If you would like to try out Sofya for yourself

I'm building a programming language. Written like that, it sounds as if I had always dreamed about compilers, read the Dragon Book cover to cover, and spent years waiting for the day I could finally design my own language. Not even close. I was just writing ordinary web applications and constantly thinking things like: "Why do I have to write it this way here?" or: "Wouldn't this feel better if I could write it a little more directly?" I kept digging into those small annoyances instead of ignoring them, one by one, and somehow they turned into a programming language. It's called Seseragi . Seseragi (せせらぎ) is a Japanese word for the gentle sound or flow of a small stream. I wanted my programming language to have a Japanese name. https://github.com/KentaroMorishita/seseragi https://seseragi.vercel.app/ https://seseragi.vercel.app/tour/ It's still experimental and pre-release, but a Rust compiler, CLI, LSP, formatter, WASM Playground, Signal, and Web UI are already working to a surprising degree. Even I sometimes look at it and think, "How far is this thing going?" It started with being tired of if In 2024, I wrote this article on Qiita. https://qiita.com/KentaroMorishita/items/6329d20fbc6f98f72864 The title alone probably tells you I was already heading somewhere weird. I don't think I hated if itself. What bothered me was the feeling of tracing conditional branches as statements . That was also why I liked ternary expressions. Not just because they were short. They were expressions, so I could take the result directly as a value. const label = isLoading ? " Loading... " : hasError ? " Error " : " Ready " Of course, once these grow, they become painful too. So I started building my own match and when abstractions on top of TypeScript. Looking back, I was trying pretty hard to fight the language. But the underlying desire was already clear: I'd rather construct values than chase control flow. When I look at Seseragi now, the symptoms had started long before the languag

submitted by /u/Realistic-Currency29 [link] [留言]

I manage the YouTube longform queue for my BuilderStack channel as JSON files in content/yt-longform-queue/ . A spec file lands there when a generator script commits a new dialogue; the publish workflow picks the file, renders it to MP4, uploads it, then moves the file to uploaded/ . No external queue service, no database rows, no management dashboard. This has worked for three months without a major incident. Four patterns kept it from collapsing. Archetype-priority picking, not FIFO First-in, first-out publishing breaks when you have product walkthrough videos, educational deep-dives, and weekly recap specs all in the queue simultaneously. A recap spec committed yesterday would block a product walkthrough from two weeks ago if the queue ran FIFO — and the product content is what actually grows the channel. The picker uses an explicit priority rank: RANK = { " product_findindiegame " : 0 , " product_ossfind " : 1 , " hidden-gem " : 1 , " build_in_public " : 2 , " technical " : 3 , " curated " : 4 , " meta " : 4 , " contrarian " : 6 , " recap " : 7 , " ai_tools " : 7 , } DEFAULT_RANK = 5 Archetypes not in the dict fall to DEFAULT_RANK = 5 — the middle, not the bottom. New formats I haven't classified yet still air rather than sitting perpetually at the end. Within each rank tier, files sort by filename (oldest-first). The archetype value comes from the spec JSON's top-level archetype field, falling back to a prefix match on the filename for older files that predate the field. One consequence: adding a new archetype name to the dict can reorder the queue overnight. I've done this intentionally to let a backlogged product video jump ahead of a stale recap. 21-day stale expiry Queue files include a date prefix: YYYY-MM-DD-<slug>.json . The picker removes files whose date is more than 21 days old before selecting what to publish: MAX_AGE_DAYS = " ${ QUEUE_MAX_AGE_DAYS :- 21 } " CUTOFF = $( date -u -d " ${ MAX_AGE_DAYS } days ago" +%Y-%m-%d ) for f in content/yt-longform

Hello Guys!!! I am Kuldeep Gade. A final-year Computer Engineering student with a specialization in Cybersecurity. Currently, I am working on home lab automation so that it will help to encounter alerts (false positives). For practice, I have created a controlled environment for performing attacks and detecting them, such that the outside doesn't get affected. Working on projects which will enhance my cybersecurity skills. But I wasn't that obsessed with cybersecurity from the starting. I am a person who experimented with lots of domains by myself. When I was in the first year, I completed Full-Stack in MERN. For 1–1.5 years, I did that, but after some time, AI got so much power that within 3–4 months of the launch, they were able to create such stunning websites that needed a team of skilled people. And I thought it could be useless to go deep into MERN more, because if AI can do such things within months, then what is going to happen at the time of my graduation? And that's the reason I tried other things. So I realised that it could be better to gain the fundamental knowledge in the core of Domains that will automatcally get to implementation level with the help of the AI tools. So I started to learn Data Science and Machine Learning. Soon, I realised that I cannot keep up with it. Then I started with cybersecurity. And currently, I am going deep into it. As a result, I got my answer, and now I am a bit focused towards the cybersecurity domain. It was a tremendous feeling about knowing the root of the system on which we are working. How to troubleshoot the errors and problems. And I am loving it now. Gaining experience in this field is not just learning and watching tutorials. We have to perform hands-on practice. We have to learn by doing things, breaking systems, understanding workflows, rebuilding them. I am going to share my experience in the field as we go in upcoming blogs. Recently, I started my new goal to "read the books". And did some research on books.

Every time someone on your team says "we'll clean it up later," they're taking out a loan. The problem is that almost nobody checks the interest rate — until it bankrupts an entire sprint. Technical debt is the most-used and least-understood metaphor in software. Used well, the metaphor is genuinely powerful, because debt is exactly the right mental model — including the part everyone forgets: interest. Debt isn't the same as bad code First, a correction. Technical debt isn't just messy or bad code. It's a deliberate or accidental trade: you took a shortcut — skipped the abstraction, hardcoded the value, deferred the test — to move faster now, in exchange for a cost later. Sometimes that's a smart, conscious decision. Shipping today to validate an idea, knowing you'll refactor if it works, is often the right call. The debt isn't the problem; unmanaged, invisible debt is. The interest is the point Here's what the metaphor gets exactly right and most teams ignore. Debt accrues interest . Every feature you build on top of a shortcut is a little harder to build. Every bug in the messy area takes a little longer to fix. The shortcut doesn't cost you once — it taxes every future change that touches it, and that tax compounds. This is why teams mysteriously slow down over time. It rarely feels like a wall; it feels like everything gradually getting harder, estimates creeping up, small changes turning into week-long ordeals. That's compounding interest on debt nobody tracked. I've watched a system's velocity get quietly reclaimed by exactly this, and paying it down deliberately is part of how I approach building things properly . Good debt, bad debt The framework that makes this actionable: Deliberate, prudent debt: "We know the right design, but we're shipping the simple version to hit the deadline, and we'll fix it." Fine — it's a conscious, tracked trade. Accidental, reckless debt: "What's a design pattern?" — debt taken on through inexperience, invisibly, with no plan t

Opening hook It happened during a quiet Friday Jumu'ah prayer. The imam had just reached the most solemn part of the khutbah when a high-pitched, insistent ringtone echoed through the entire hall. Heads turned, whispers started, and the person responsible scrambled to silence their device, only to fumble and drop it in their haste. I sat there, mortified for them, knowing exactly how that sinking feeling felt. It is the universal experience of the modern digital age: the gap between our intentions to be polite and our actual ability to manage our phone's state in public spaces. The problem We live in a world of constant notification, yet we lack a standard way to govern our devices based on our physical context. Android provides AudioManager and NotificationManager , but these are reactive tools that require manual input. I tried using standard alarm-based triggers, but they lacked the spatial awareness I needed. If I am at the office, I want my phone on vibrate. If I am at home, I want it back to normal. If I am at a medical clinic, I need it on silent. Most existing solutions rely on heavy GPS polling, which drains the battery within hours. They treat location services as a raw stream of coordinate data rather than a state-based trigger. I wanted something that functioned entirely in the background, survived system reboots, and operated without a constant drain on the user's battery life. The friction wasn't just about silence; it was about the cognitive load of having to remember to switch profiles. I wanted my phone to handle the context switching for me, autonomously and reliably, without becoming a battery-draining nightmare. The technical decision / implementation To solve this, I moved away from manual polling and adopted the GeofencingClient within the Google Play Services location APIs. The decision to use this over raw LocationManager updates was rooted in battery efficiency. The GeofencingClient pushes the heavy lifting to the OS level. It uses a combina

The Quest Begins (The "Why") I still remember the first time I opened a pull request that looked like a novel written by someone who’d had too much coffee. The file was 800 lines long, a single function tried to validate input, fetch data from three different APIs, transform the result, update the UI, and log everything to a console that no one ever looked at. I spent three hours stepping through it with a debugger, only to realize the bug was a typo in a variable name buried three levels deep in a nested if‑statement. When I finally fixed it, I felt like I’d just defeated a dragon… only to discover the dragon had a dozen smaller dragons hiding in its caves. That experience left me wondering: Why does code feel so hard to read, even when it works? The answer wasn’t a fancy framework or a new language feature—it was a simple habit I’d overlooked: making every function do one thing, and do it well . Once I started treating that rule like a sacred oath, the dragons started to shrink, and my code began to feel like a clean, well‑lit hallway instead of a dark, tangled forest. The Revelation (The Insight) The principle is straightforward, yet its impact is massive: each function should have a single responsibility . If you can describe what a function does with a single verb phrase— validateUserInput , fetchUserProfile , renderDashboard —you’re on the right track. If you need an “and” or a “but” in that description, you’ve probably got more than one job packed in. Why does this matter? Readability : A reader can grasp the intent in seconds, not minutes. Testability : Small, focused functions are trivial to unit test. You can mock dependencies and assert outcomes without setting up a whole saga. Debugging : When something goes wrong, the stack trace points you directly to the guilty function, not to a 20‑line monolith where you have to hunt for the offending line. Reusability : A function that does one thing well can be dropped into other parts of the codebase (or even oth

Quieres mandar la misma notificación a varios sitios: Slack, Discord, un webhook, un email. La primera versión es un for de tres líneas: for canal in canales : canal ( mensaje ) Y funciona en las demos. Hasta que un día Discord devuelve un 500, canal(mensaje) lanza, y el email y el Slack que iban detrás nunca salen . Peor: te enteras por el usuario que no recibió la alerta, no por un log. Dos cosas fallan en ese for : No aísla. La primera excepción corta el reparto entero. No reporta. O cada canal se traga su error en un try/except disperso, o el fallo se pierde. La forma correcta Aísla cada canal y recoge el resultado. Lo empaqueté como fanout-broadcast —Python puro, sin dependencias— porque lo reescribía en cada proyecto: from fanout_broadcast import Broadcaster bc = Broadcaster () bc . add ( " discord " , a_discord ) bc . add ( " telegram " , a_telegram ) bc . add ( " email " , a_email , enabled = False ) # apagado por ahora report = bc . broadcast ( " ¡Nueva versión publicada! " ) if not report . ok : for o in report . failed : log . error ( " %s falló: %s " , o . name , o . error ) broadcast llama a todos los canales habilitados, captura la excepción de cada uno por separado , y sigue con el siguiente. Un Discord caído ya no impide que salga el email. Al final tienes un reporte: report . ok # ¿ningún canal falló? report . delivered # los que entregaron report . failed # los que lanzaron (cada uno con su .error) report . skipped # los que estaban deshabilitados Encender y apagar sin ramificar el código Cada canal tiene un interruptor, en runtime o por variable de entorno: from fanout_broadcast import env_enabled bc . add ( " discord " , a_discord , enabled = env_enabled ( " discord " )) # mira DISCORD_ENABLED Esto importa más de lo que parece: separa qué canales existen de cuáles están activos hoy , sin comentar código ni meter if por todos lados. Apagas un canal problemático con una variable de entorno, no con un despliegue. Escalar, pero después de intentarlo

When Google open-sourced cgroups—a foundational Linux feature it developed internally—few realized it would quietly become the backbone of today's multi-trillion-dollar cloud industry. submitted by /u/Ok_Stomach6651 [link] [留言]

The Agentic Coding Revolution: How I Learned to Stop Typing and Start Delegating Or: what happens when your IDE becomes less of a text editor and more of a teammate. Remember when "AI-assisted coding" meant autocomplete suggestions that guessed your variable names? Those days are gone. Somewhere along the way, the tools stopped suggesting and started doing . They read your repo, run your tests, open pull requests, and sometimes fix bugs you didn't even know existed. Welcome to the era of agentic coding — and if you haven't restructured your workflow around it yet, this post is your crash course. What Actually Changed? The shift from code assistant to coding agent comes down to one capability: autonomy . A traditional assistant waits for your keystrokes. An agent receives a goal and figures out the rest. Dimension Code Assistant Coding Agent Trigger Your keystroke A stated objective Scope Single line or block Entire task, across files Feedback loop None Reads test output, retries, iterates Tool use Suggestion only Shell, browser, git, package managers Ownership You write, it suggests It drafts, you review The mental model that helped me most: stop thinking of the agent as an autocomplete and start thinking of it as a junior developer with access to your codebase. You wouldn't hand a junior engineer an undocumented task with no acceptance criteria. So why hand it to an agent? The Prompting Gap Is the New Debugging Here's the uncomfortable truth I discovered after a few months of daily agentic workflows: agents don't fail because they're dumb. They fail because our instructions are vague. Consider these two requests: ❌ Bad: "Make the app faster" ✅ Good: "Reduce p95 latency of the /search endpoint (currently 1.2s) to under 300ms. Focus on the database query layer first. Keep existing API contracts unchanged. Add a benchmark comparing before/after." The second version has a measurable goal, a constraint boundary, a starting hypothesis, and a definition of done. Agents th

In 2009, Craig Gentry proved that it is possible to compute on encrypted data without ever decrypting it, and the result was widely treated as a theoretical curiosity. Sixteen years later, homomorphic encryption has crossed from conference papers into production pipelines: banks screen transactions against encrypted watchlists, hospitals run diagnostic models on data that never leaves their custody, and in August 2026 Google announced private AI features built on the same primitives. The gap between "possible in theory" and "usable in practice" is still wide, but it is no longer an argument against trying. This guide walks through what homomorphic encryption actually computes, how the CKKS scheme turns encrypted vectors into a workable substrate for machine learning, and the cost model that decides whether a private inference pipeline is worth building at all. The Promise: Compute Without Reading Ordinary encryption has a hard property: a ciphertext reveals nothing about the plaintext. AES-CTR, ChaCha20, RSA — all of them scramble data so thoroughly that an attacker holding the ciphertext and a supercomputer cannot recover the message without the key. That property is also the problem. If a server stores customer data encrypted at rest, every query requires shipping the data (or the key) somewhere a human or a process can read it. The moment the data is decrypted for computation, the confidentiality boundary moves from the storage layer to the memory of whatever process is doing the work. Homomorphic encryption changes the terms. A homomorphic scheme is one where operations on ciphertexts correspond to operations on plaintexts: Enc(a) ⊕ Enc(b) = Enc(a + b) . A server can add, multiply, and combine encrypted values and return the encrypted result, and the client — the only party holding the key — decrypts the final answer. The server learns nothing about the inputs, the intermediate values, or the output. For inference, this is the entire ballgame: the model owner ne

It was during the peak monsoon season when I read a distress report from a family stranded on their rooftop. Power was flickering, rain was hammering against the walls, and cellular data was down to a crawling 2G edge. They had a phone with 14% battery, but opening an emergency app or downloading heavy government disaster PDFs was impossible. All they could do was place a direct phone call. That moment stayed with me. When panic sets in and water is rising inside your living room, you don't navigate drop-down menus or type search queries into a browser. You need to speak, and you need a voice that answers immediately with verified life-saving relief info. That became the driving mission behind Sentinel — an autonomous, real-time Voice AI emergency dispatcher that I built over 10 days during the #VoiceForBharat challenge. The Problem I Wanted to Solve In emergency response across India, victims and disaster managers face three immediate hurdles: Information Fragmentation: Emergency guidelines, live rainfall alerts, and shelter capacities exist across different departments. A caller in panic needs instant answers (e.g., "Is there a shelter in Guwahati with medical support and space for pets?" ). The Friction of Touch UIs: Wet screens, low digital literacy, and high adrenaline make text interfaces fail. Voice is the most natural, accessible lifeline. Context Collapse: When standard chatbots escalate a user to another team or system, they drop the context and force the distressed victim to repeat their story from scratch. How Sentinel Works Under the Hood To make Sentinel feel like a natural human dispatcher, every millisecond of latency had to be eliminated. The system streams voice bidirectionally through a unified WebRTC pipeline: Speech-to-Text (STT): Deepgram Nova-3 transcribes incoming audio streams in real time with multilingual code-mixing support (English & Hindi). Brain & Reasoning (LLM): Google Gemini handles real-time disaster triage, safety guardrails, and