标签：#RAM

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

Hello everyone! This is the second article about the development of RUSEON-core, a Zero-Copy video streaming server for AI platforms and Edge video infrastructure. In the first article , I talked about the fundamental reason why we decided to create our own server in the first place. I also covered the main problem with most similar solutions — the "thundering herd" — and how we managed to squeeze out 8 Gbps on a single CPU core. By the way, I forgot to mention in that article that besides simple streaming, we also record the streams in fMP4 format. It’s stored locally for N amount of time, and it can fly off to an S3 bucket (depending on how long the clients want to keep the recordings). This article is precisely about a non-obvious (well, at least to me, maybe for someone else it's an everyday thing) problem related to data storage and its specifics across all Operating Systems. So, let's dive in. We rolled out our first release to production (100 cameras), made the clients happy, and started working. About an hour passed, and the alerts started flying. I SSH into the server, open htop, and see there's only 100 MB of free RAM. Uh-oh. I should clarify that the production server had 32 gigs of RAM. The expected behavior was that the CPU is chilling, the network card is chewing through the traffic, RAM usage is around 250-300 MB, and the disks are not heavily loaded. So, when you see numbers like that in htop, you start blaming yourself and your crooked hands that wrote this piece of "garbage". But still, we decided to go to Google, ChatGPT, and the like. Fortunately, the answer was found quickly, and we stopped beating ourselves up. The code was absolutely not the culprit; Linux itself ate the memory. If you've ever written tons of data to a disk, I think you already know what’s going on. There is an "invisible enemy" known as the Page Cache. That was exactly the root of this problem. How does the Page Cache work and what to do with it? When your function that is su

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

Everyone is building agents. You should build escape hatches. We are living through the most expensive group hallucination in tech history. Every SaaS now has a chatbot stapled to it. Every CEO is an "AI thought leader" on LinkedIn. Every startup pitch deck is just the words "autonomous," "agentic," and "10x" in different fonts. NVIDIA could buy a small country. OpenAI burns through more cash in a quarter than NASA did getting to the moon. And for what? So you can generate slightly worse emails, slightly faster? Look, I love AI. I actually build with it. But I have been around long enough to know what a bubble smells like. It smells like free credits, unearned confidence, and a thousand wrappers around the same API call. The bubble will pop. Not in a dramatic, newspapers falling from the sky way. It will pop quietly. Credits will dry up. Models will get paywalled behind enterprise tiers. The cloud bill you have been ignoring will finally show up. And all those beautiful, cloud-dependent workflows you built will start blinking red. So while everyone else is trying to figure out how to make their AI agent book a flight, I have been asking a different question. What do you build when you assume the internet will get worse, the cloud will get more expensive, and you will need actual skills that survive a downturn? The answer, annoyingly, is two pieces of junk from Amazon that cost less than your last Uber Eats order. Piece of Junk #1: The $25 Router That Sees Everything It is not sexy. It is called the GL.iNet GL-MT300N-V2. Everyone calls it the Mango. It looks like a little yellow box that should have come free with your ISP in 2014. You can buy it on Amazon for about twenty six dollars when it is on sale. Sometimes twenty. Inside it is a tiny Linux computer running OpenWrt. It has two ethernet ports, a USB port, and just enough RAM to be dangerous. Most people buy it to get free WiFi in hotels. I bought it to spy on my own network. Because here is the dirty secret of

submitted by /u/compilers-r-us [link] [留言]

Near the end of a release, every file transfer to the production server succeeded, and the version file that triggers distribution was updated too. With that confirmed, the release got reported as complete — except the local git repository never actually had those changes committed. Note: "Deploying" here means transferring changed files to the production server (via scp, for example) so they're actually live for users. "git push" is a separate operation that records the change history in a remote repository. What happened This release involved transferring seven files to the production server: five landing-page update-notice files, the version file that triggers distribution, and a progress-log file. The transfer itself succeeded completely, and the production site confirmed it was showing the new version number. The problem: after editing these files locally, the work moved straight to the transfer step without ever committing . The files on the production server were fully up to date, but the local git repository had no record of those changes — and the release got reported as complete in that state. Why this is easy to miss Transferring files with scp and recording them in the repository with git commit / git push are completely independent operations, both as commands and as goals. Verifying production (HTTP 200, checking the rendered content) confirms "did the deployment succeed" — a different question from "is the local change history recorded." Treat the first check as proof of "done," and the second check quietly never happens. When both steps get mentally bundled into one "release complete" state, there's no natural moment to notice that only one of them actually finished. In this case, it surfaced because someone else looking at the repo noticed it hadn't been committed yet. The fix — treat "uploaded" and "git synced" as two separate checks Add a git-sync verification step to the deploy checklist, independent from the file-transfer confirmation. # Commit

Yes! this was about 12 years ago, when I was just a little 10 year old girl. I was very lazy even...

submitted by /u/tech-tinkerer-19 [link] [留言]

Ho bloccato gli attacchi xss e l'estrazione della chiave API nel browser modificando monkey-patch crypto.subtle. Perché non lo fa nessun altro? Here is how I hardened the browser runtime for a Zero-Knowledge, Non-Custodial FinTech trading terminal. 👇 2/ Client-Side Envelope Encryption: I derive a KEK from the user's password using PBKDF2-SHA256 (310,000 iterations). Then, a secure random 32-byte DEK (AES-256-GCM) encrypts the data. The password NEVER touches the server, and the DEK has a strict 15-min TTL in RAM before a wipe. 3/ Secure Enclave Anti-Export Guard: CryptoKeys are generated via crypto.subtle with {extractable: false}. To prevent injected malicious scripts from bypassing the sandbox, I implemented an isolated closure that overrides (monkey-patches) the native browser API: 4/ crypto.subtle.exportKey = async function(format, key) { if (isProtectedKey(key)) { _AuditChain.append('EXPORT_ATTEMPT', 'CRITICAL'); throw new Error('Export BLOCKED — unauthorized'); } return _origExport(format, key); }; 5/ If our database is breached, hackers find ZERO financial data. If the local session is compromised, runtime gating blocks extraction. Plus, client-side validation rejects API keys with withdrawal permissions enabled (zero custodial risk under MiCA, built for GDPR). 6/ The entire architecture runs client-side (WebSocket throttled at 100ms + local AI Advisor), keeping server costs near zero. Where does this runtime isolation logic fail? Why do major SaaS platforms still rely on standard local storage? Let's discuss. 💬 submitted by /u/Fit-Document9226 [link] [留言]

I manage a dev team, and we've been running Claude Code daily for months. I built a set of custom skills for us — code review, a debugging protocol, our team conventions — and the biggest lesson I learned surprised me: The body of your skill barely matters if the description is wrong. The failure mode nobody warns you about Here's what happens to most developers who discover skills. They get excited, write a detailed 200-line SKILL.md encoding everything they know about code review... and then it never triggers. Not once. They conclude skills "don't really work" and go back to re-typing the same prompt every session. The skill was probably fine. The description killed it. The description is a routing rule, not documentation A skill's description is the only part Claude sees upfront. The full instructions load only after the description matches your request. So the description isn't marketing copy — it's a routing rule, and it needs to be written like one. Compare: # WEAK — reads nicely, never triggers description : Helps with code quality and best practices. # STRONG — names the situations AND the phrasings description : Security-first code review for Python/FastAPI. Trigger when the user asks to "review", "check", or "look at" code, pastes a function or endpoint, mentions a bug, or asks "what's wrong with this". Also trigger on short requests like "review this". The difference: the strong version contains the actual words you type. Including the lazy ones. Nobody writes "please perform a comprehensive quality assessment" at 11pm — they write "review this". If your description doesn't cover the two-word tired version, your skill sleeps through most of your real requests. Three rules that fixed my skills 1. List your real trigger phrases. Open your chat history and look at how you actually phrase requests. Those exact phrases go in the description — "fix it", "what's wrong here", "check this". Your real vocabulary, not your professional vocabulary. 2. Name the artifa

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

System Design is the process of planning how a software system should work before building it. Think about constructing a large building. Before workers start putting up walls, architects decide where the rooms, elevators, electricity, water systems, emergency exits, and entrances should go. Software works in a similar way. When developers build applications such as Amazon, Instagram, Netflix, Uber, or WhatsApp, they cannot simply start writing code and hope everything works. They first need to decide how millions of users, servers, databases, files, and requests will work together. A simple way to remember it is: System Design = The blueprint of a software system. What Do We Decide in System Design? During system design, engineers make decisions about things such as: How users connect to the application Where information is stored How different parts of the application communicate How images and videos are stored How the system handles millions of users How the application stays fast How failures are handled How user information stays secure For example, imagine designing WhatsApp. A user sends a message. That message must travel to WhatsApp's servers, reach the correct person, possibly be stored temporarily, appear on multiple devices, and trigger a notification. If millions of people send messages at the same time, the system must continue working without becoming extremely slow or crashing. That planning is system design. Why Does System Design Matter? A good software system should be: Fast Reliable Secure Scalable Affordable to operate Easy to maintain Imagine Instagram without good system design. Millions of users might open the application at the same time. Servers could become overloaded, photos might take several seconds to load, comments could disappear, and the application might frequently crash. System design helps engineers prepare for these situations before they become major problems. System Design in Software Interviews System design is also common i

Remember when "AI coding" just meant inline tab-completion suggesting a for loop in VS Code? Those were simpler times. 😅 Fast forward to this week, and we’ve officially crossed the threshold into the Autonomous Multi-Agent Era . The industry is shifting away from single-turn autocomplete prompts toward async, parallelized agentic workflows that inspect, plan, write, test, and validate code across entire repositories. Three major developments dropped almost simultaneously: ⚡ Meta launched Muse Code (powered by Muse Spark 1.2) in beta, introducing parallel sub-agent execution. ☁️ AWS added an Agentic Workspace to Kiro , enabling async background task delegation for developers. 🎓 New Academic Research surfaced on how AI coding agents leverage structured "Agent Plans" for full-lifecycle repo maintenance, design, construction, testing, and validation. Let's break down why this is a massive engineering paradigm shift and what it actually means for our daily developer workflows. 🧬 1. Meta Muse Code & Parallel Sub-Agent Swarms Meta’s latest drop— Muse Code , driven by their Muse Spark 1.2 model—takes aim at one of the biggest bottlenecks in single-agent LLM systems: context dilution and linear execution delays . When you ask a traditional LLM to refactor a complex microservice, it processes everything sequentially. It reads your files, thinks, writes code, tries to debug, and eventually runs out of context space or hits token output limits. How Parallel Sub-Agent Execution Changes the Game Muse Code doesn't just run one linear chat session. Instead, a primary orchestrator agent decomposes a high-level goal into specialized sub-agents running concurrently: ┌──────────────────────────────┐ │ PRIMARY ORCHESTRATOR AGENT │ └──────────────┬───────────────┘ │ ┌──────────────────────────┼──────────────────────────┐ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ SUB-AGENT A │ │ SUB-AGENT B │ │ SUB-AGENT C │ │ AST Parsing & │ │ Unit Test Suite │ │ Static Analysis

Tienes una señal que a cada observación te dice en qué estado estás: un monitor de salud que dice OK o CAÍDO , un detector de conectividad, un clasificador de modo. Y cerca del umbral oscila : OK, CAÍDO, OK, CAÍDO, OK . Cada cambio dispara algo —una alerta, un failover, entrar o salir de una posición— y de repente tu sistema está temblando por ruido, no por una transición real. Es el mismo problema que resuelve el termostato de tu casa desde hace un siglo, y la solución tiene nombre: histéresis . No cambies de estado hasta que el nuevo se haya sostenido. La regla, en una frase Un estado nuevo solo se confirma tras repetirse N observaciones consecutivas. Si el candidato cambia o revierte antes de llegar a N , la cuenta se reinicia. El estado vigente se mantiene estable; los parpadeos se ignoran. Lo empaqueté como librería — hysteresis-state , Python puro, sin dependencias— porque lo reescribía una y otra vez: from hysteresis_state import HysteresisState estado = HysteresisState ( " OK " , confirmations = 3 ) for lectura in stream : # "OK" / "CAIDO" actual = estado . update ( lectura ) # solo cambia tras 3 lecturas seguidas if estado . changed : # ¿esta lectura provocó la transición? alertar ( actual ) Aliméntalo con OK, CAÍDO, OK, CAÍDO, OK y no pasa nada: ningún candidato se sostuvo. Hacen falta tres CAÍDO seguidos para que el cambio se confirme. El detalle que casi siempre falta: histéresis asimétrica Un umbral único tiene un problema sutil. Si exiges 3 confirmaciones para entrar en fallo, también tardas 3 en salir — y a veces quieres justo lo contrario: caer rápido a lo seguro, volver despacio a lo arriesgado . Es el comportamiento de un disyuntor eléctrico: salta a la primera, se rearma con cautela. Se resuelve dejando que el umbral dependa de la transición: # 1 confirmación para caer a "CAIDO", 5 para volver a "OK" conf = lambda desde , hacia : 1 if hacia == " CAIDO " else 5 estado = HysteresisState ( " OK " , confirmations = conf ) estado . update ( " CAIDO " )

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

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

E-graphs, originally developed for use in automated theorem provers, are data structures that compactly represent a large number of expressions and the equalities between them. The egg library is a fast and flexible open-source implementation of e-graphs and equality saturation. It has been used in hundreds of academic and industrial projects for program optimization, synthesis, and verification in many domains; some are briefly highlighted in this article. Direct link to the publication: https://dl.acm.org/doi/10.1145/3815481 Summer 2026 submitted by /u/Choobeen [link] [留言]

A few days ago, I went for an internship opportunity that I was genuinely excited about. I had been looking forward to it for a long time. When I got the opportunity to attend a 3-day demo/trial period , I went in with a lot of excitement. I wanted to prove myself, learn as much as possible, and hopefully turn those three days into something bigger. And honestly, I gave it my best. I showed up, worked, learned, asked questions, and tried to contribute wherever I could. Then came the moment I had been hoping for. I received the offer letter. ❤️ For a moment, I was extremely happy. After being out of college and working hard to build my skills, finally getting an offer felt like a big step forward. But then I had to look at the practical side. The internship was work from office , and the stipend was ₹7,000/month . The biggest challenge was the distance. I live around 90 km away from the office. When I calculated the daily travel, food, and other expenses, I realized that accepting the internship would put a huge financial burden on me every month. And that was a very difficult realization. Because emotionally, I wanted to say: "Yes, I got an internship. Let's do this!" But practically, I had to say: "I can't afford this right now." So I rejected the offer. And honestly? It hurts. Not because the company did something wrong. Not because I didn't want to work. But because I finally got an opportunity I was excited about, gave it my best during the trial period, received the offer… and still had to walk away from it. I've been feeling pretty bad about it. There is always this thought in the back of my mind: "What if I had just accepted it?" But I'm also trying to remind myself that rejecting one opportunity doesn't mean I've failed. Sometimes an opportunity can be good and still not be right for your current situation. I'm taking this experience as a lesson: Getting an offer is not the final goal. Salary/stipend matters. Location and travel expenses matter. Your time ma

Introdução A Programação Orientada a Objetos nasceu com a linguagem Simula 67 , considerada a primeira linguagem orientada a objetos, e foi consolidada e popularizada por Smalltalk nos anos 1970. Ganhou adoção massiva na indústria com C++ e, posteriormente, Java e C#. A ideia central é organizar o código em torno de objetos : unidades que combinam dados (atributos/estado) e comportamento (métodos) em uma única estrutura. Os quatro pilares Encapsulamento — os dados internos de um objeto são protegidos e só podem ser acessados/alterados através de métodos expostos, escondendo detalhes de implementação do mundo externo. Abstração — o objeto expõe apenas o que é relevante para quem o utiliza, escondendo a complexidade interna (ex.: você chama CalcularSalario() sem precisar saber como o cálculo é feito por dentro). Herança — uma classe pode herdar atributos e métodos de outra, permitindo reaproveitamento e especialização (uma classe Desenvolvedor pode herdar de Funcionario ). Polimorfismo — objetos de classes diferentes podem responder de forma diferente ao mesmo "chamado" (o mesmo método CalcularSalario() se comporta de forma distinta para um Desenvolvedor e para um Gerente , por exemplo). Exemplo // Exemplo de Programação Orientada a Objetos em C# public abstract class Funcionario { public string Nome { get ; } protected decimal SalarioBase { get ; } protected Funcionario ( string nome , decimal salarioBase ) { Nome = nome ; SalarioBase = salarioBase ; } // Abstração: cada subclasse decide como calcular seu próprio salário public abstract decimal CalcularSalario (); } public class Desenvolvedor : Funcionario { private int BonusPorProjeto { get ; } public Desenvolvedor ( string nome , decimal salarioBase , int bonusPorProjeto ) : base ( nome , salarioBase ) // Herança { BonusPorProjeto = bonusPorProjeto ; } // Polimorfismo: implementação específica do método herdado public override decimal CalcularSalario () { return SalarioBase + BonusPorProjeto ; } } public class Gere

Introdução A Programação Funcional tem raízes no cálculo lambda , formalizado pelo matemático Alonzo Church nos anos 1930, décadas antes da existência de computadores modernos. Sua primeira grande expressão em linguagem de programação foi o Lisp (1958), e o paradigma ganhou força prática com linguagens como Haskell, Erlang, F# e, mais recentemente, com a incorporação de recursos funcionais em linguagens multiparadigma como JavaScript, C# e Python. Princípios centrais Funções puras — dado o mesmo input, uma função pura sempre retorna o mesmo output, sem produzir efeitos colaterais (não altera variáveis externas, não grava em disco, não modifica o argumento recebido). Imutabilidade — os dados não são alterados após criados; em vez de modificar uma estrutura existente, cria-se uma nova versão com a alteração aplicada. Funções de primeira classe / funções de alta ordem — funções podem ser tratadas como qualquer outro valor: armazenadas em variáveis, passadas como argumento e retornadas por outras funções. Composição de funções — programas são construídos combinando funções pequenas em pipelines ( map , filter , reduce são os exemplos mais comuns no dia a dia). Recursão no lugar de laços mutáveis, já que, sem estado mutável, for / while tradicionais perdem o sentido em sua forma pura. Como não há estado compartilhado sendo alterado por múltiplas partes do código, o raciocínio sobre o comportamento do programa fica mais previsível — e a paralelização se torna muito mais segura, já que não existe o risco clássico de condições de corrida sobre uma mesma variável mutável. Exemplo // Exemplo de Programação Funcional em TypeScript type Produto = { nome : string ; preco : number }; const produtos : Produto [] = [ { nome : "Notebook" , preco : 3000 }, { nome : "Mouse" , preco : 50 }, { nome : "Teclado" , preco : 150 }, ]; // Função de alta ordem que retorna outra função (currying) const aplicarDesconto = ( percentual : number ) => ( preco : number ) => preco * ( 1 - percentual )