标签：#RAM

I’ve started working on my own Selfhosting Cloud Service, 2 Weeks work to get the basics done. Programming in Golang, understanding Docker, Caddy and how to use a terminal to do commands 😅 I’ve included AES-256 decryption for datas, a license key to check if a license is valid. Its own right-wing administration. All in one to install all dependencies at install. Any idea what could add more safety, or features I didn’t planned myself actually? submitted by /u/CaptainPM-Ger [link] [留言]

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

The most dangerous moment in an AI-built app project is not when the code breaks. It is earlier. It is the moment where your idea is still blurry, the AI coding tool is sitting there politely, and you type: Build me an app that... That sentence feels productive. It also gives the tool permission to make a pile of decisions you have not made yet. Who is the app for? What is version one? Which workflow matters first? What data has to exist? What should not be built yet? What would make the first version successful? If those answers are missing, AI has to guess. And AI guessing at product shape is how beginners end up with a login system, dashboard, profile editor, notifications panel, admin area, billing flow, and settings page before one real user problem has been solved. That is not momentum. That is software confetti. I like AI coding tools. I use them heavily in real app work. But the tool gets much better when the project has boundaries before code starts changing. So before you ask AI to code your first app, run the idea through a checklist. Not a giant business plan. Not a pitch deck. Not a 47-tab spreadsheet that makes you feel like you joined a corporate strategy retreat by accident. A practical beginner checklist. The goal is simple: turn a rough app idea into something AI can help you build without inventing the whole product for you. 1. Can You Name The Person? Do not start with "users." Start with one person you can picture. Bad: This app is for people who want to be more productive. Better: This app is for freelance designers who need one place to track client feedback, revision status, and final file delivery. Bad: This app is for musicians. Better: This app is for guitarists who want to capture riff ideas quickly on their phone without opening a full mobile studio app. Bad: This app is for students. Better: This app is for college students who want to scan textbook chapters and turn them into study notes before an exam. When you name the person, the ap

Why Your SOE Resume Needs a Structural Overhaul Chinese state-owned enterprises (SOEs) often have deep hierarchical structures and a culture of collective achievement. But Western tech companies want to see individual impact, autonomy, and data-driven results. Continuing to lead with your former employer's prestige or your rank (e.g., "Senior Engineer Grade 7") wastes valuable space. The solution: reshape every section to answer the question "What did you personally accomplish with data?" The Core Shift: From Hierarchy to Impact In a Chinese SOE resume, it's tempting to list departments you led or teams you oversaw. In a Western senior data scientist resume, focus on the problems you defined, the algorithms you deployed, and the revenue, cost savings, or user metrics that improved. For example, instead of "Led the data analytics team of 10 people," write "Designed and deployed a demand-forecasting model that reduced inventory costs by 15% (¥12M annually)." Three Resume Sections That Require Full Rewriting Professional Summary: From 'Accomplished Engineer' to 'Data Science Leader' Start with your total years of experience, your technical stack, and the types of business problems you solve. Example: "Senior Data Scientist with 10+ years applying machine learning to supply chain and logistics. Expertise in Python, TensorFlow, and Spark. Reduced operational costs by 15-30% through predictive models deployed at [SOE name]." Work Experience: From Role Descriptions to Metric-Driven Bullets For each role, list 3-5 bullets. Every bullet should have a verb, a task, a technology (if relevant), and a quantified result. Avoid vague phrases like "responsible for." Use specific numbers: "Improved forecast accuracy from 70% to 85% by building an ensemble of ARIMA and XGBoost models." Education & Certifications: Emphasize Transferable Skills Your Chinese degree is fine, but add relevant certifications (AWS, TensorFlow, Coursera) to show adaptability. Consider a "Technical Skills" se

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

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

submitted by /u/sohang-3112 [link] [留言]

A few years into my career, I went back to a project I'd built solo about eighteen months earlier. I was proud of it at the time. It had a custom state management solution, several layers of abstraction, a utility library I'd assembled myself, and what I distinctly remember thinking of as "a robust architecture." Reading through it again, I spent twenty minutes just trying to understand why I'd built a particular module the way I had. The logic was split across four files. There were abstractions on top of abstractions. Two functions did nearly the same thing with slightly different names. A third was never called anywhere. The worst part wasn't the code itself. It was realizing that a simpler version, one I could have written in a day instead of a week, would have done exactly the same thing with a fraction of the complexity. That experience changed how I think about software development more than any course, book, or conference ever did. Writing less code, genuinely less, often requires more thinking than writing more. And the developers who figure that out early tend to produce work that holds up significantly better over time. Why More Code Doesn't Mean Better Code There's a belief that's easy to absorb early in a development career, that skill shows up in volume. More features, more files, more clever solutions. A complex system feels like proof that something serious was built here. That feeling is almost entirely wrong. More code means more surface area for bugs. Every line is a line that can break, a line that needs to be read, a line that needs to be tested, a line that a new team member has to understand before they can confidently change anything. None of those costs are trivial, and they compound. Complexity hides bugs. A simple function with one responsibility is easy to test and easy to debug. A function that does five things, or calls three other functions that each do three things, creates a web of possible failure points that's genuinely difficult t

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. Every CS program hammers the same seven into you. Arrays, linked lists, hash tables, stacks, queues, graphs, trees. You could probably recite their Big O complexities in your sleep at this point, and honestly, for 90% of the code you'll ever write, that's plenty. But every now and then a system hits a wall that none of the seven basics can handle gracefully, and someone had to invent a weirder tool to patch the gap. I went down a rabbit hole recently looking at a handful of these, and I liked them enough that I wanted to write them up properly instead of just leaving forty open tabs to rot. Fair warning, there is some depth here. Get a drink. When your hash table can't promise you a fast answer: Bloom filters Normal hash tables are great until you need to ask "have I possibly seen this before" across a dataset way too big to store in memory. Think a crawler checking billions of URLs, or a database deciding whether it's even worth going to disk to look for a row. A Bloom filter solves this by giving up on certainty in one direction. It's a fixed array of bits, plus a small handful of independent hash functions. Adding an item flips a handful of bits on. Checking for an item hashes it the same way and checks whether those same bits are on. If any single bit is off, that item was never added, full stop, no ambiguity. If they're all on, the item was probably added, but two unrelated items can accidentally light up the same bits, so you might get a false alarm. The asymmetry is the entire design. Zero false negatives, occasional false positives. It's the data structure equivalent of a metal detector at a stadium gate. It'll never wave through someone with a knife, but it might beep at your belt buckle and make you empty your pockets for nothing.

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

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

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

From order, chaos. From courage, fear. From strength, weakness. — The 36 Stratagems, "Make a Sound...

I’ve wanted to build a text editor for a long time. Not because I thought the world needed another one — it clearly doesn’t — but because editors are one of those projects where you end up touching everything: rendering, input handling, text buffers, undo, plugins, configuration, even OS integration. It felt like the most honest way to learn how these tools actually work. So I finally did. cdin is a lightweight, keyboard-centric text editor with Vim-style modal editing. It started as a fork of lite , but over time it became something more personal. I kept the parts I liked, removed the parts I did not, and reshaped the rest to match the way I actually work. A big reason for that was my computer. I have a weak machine, and that made heavier text editors feel frustrating to use. They were often slow, laggy, or just too much for what I needed. That is how I discovered lite in the first place. It was close to what I wanted, but not quite there. So I forked it, renamed it to cdin, and started making it mine. That meant more than just small tweaks. I removed features I did not need, changed the things that felt awkward, moved from SDL2 to SDL3, and rewired a lot of the project structure along the way. The result is cdin: a small editor built around speed, simplicity, and hackability. The name itself is simple too. cdin means “CODE in”. The code is split between C and Lua. The C side handles the window, renderer, and SDL bindings. Everything else — behavior, plugins, keybindings, config — is loaded in Lua at runtime. That keeps the editor flexible without making it feel heavy. If you want to explore the project, here are the main docs: Overview · Getting Started · Building from Source · Configuration · Vim Keybindings · Plugins · Command Reference There is still a lot I want to improve, but cdin already feels like something that belongs to me in a way no other editor ever did. If you check it out, please leave a star, fork it, or send an Issue or PR if you find a bug or wa

Hi everyone, My Microsoft SWE internship is coming to an end, and I have my technical exit interview/final evaluation coming up. If you've gone through this interview before, could you share your experience? Some questions I have: What kind of technical questions were asked? Was it mainly DSA, OS,DBMS What difficulty level should I expect? Any tips on what I should focus on during the last few days of preparation? I'd really appreciate hearing about your experience. Thanks in advance! submitted by /u/CabinetFamous4731 [link] [留言]

I'm a 20-year-old computer science student leading the development of a software project called Skyline Computer World. Rather than rushing into features, I decided to start with the architecture: designing the database, setting up NestJS, PostgreSQL, Prisma, and establishing a modular backend structure. The process has involved plenty of debugging, redesigning, and learning—from Prisma migrations to project organization—but it's reinforced how important a solid foundation is for long-term maintainability. I'd be interested to hear from more experienced backend engineers: What architectural decision had the biggest long-term impact on one of your projects? If you were starting a backend from scratch today, what would you do differently? submitted by /u/amjakez [link] [留言]

In the field guide I covered what an AGENTS.md is and what belongs in it. This is the hands-on follow-up: we'll build a complete AGENTS.md for a real project, one section at a time, then point an AI coding agent at it and watch the difference it makes. By the end you'll have a working file — and you'll have seen it pay off. New to AGENTS.md? It's a single Markdown file at the root of your repo that tells AI coding agents how to work in it — build steps, tests, conventions, guardrails. The "why" behind each section is in the field guide . The project we'll use We'll write the AGENTS.md for a small but real service: a URL shortener API in Python — FastAPI, SQLite, pytest. A couple of endpoints, a thin data layer, a test suite. Follow along with this, or swap in your own repo — the steps are identical. Its shape: linkshort/ app/ main.py # FastAPI routes db.py # SQLite access models.py # Pydantic models migrations/ # generated SQL — not hand-edited tests/ requirements.txt Step 0 — Start with an empty file At the repo root: touch AGENTS.md That's the whole step. We'll fill it in one section at a time, building toward a file an agent can read in thirty seconds. Step 1 — Orientation: one line Tell the agent what it's looking at. Add: # AGENTS.md A URL shortener API in Python — FastAPI, SQLite, pytest. One sentence sets the agent's priors: it knows the language, framework, and storage before it reads a single line of code. Step 2 — Setup and run The agent can't help if it can't start the project. Add the real, copy-pasteable commands: ## Setup python -m venv .venv && source .venv/bin/activate pip install -r requirements.txt ## Run uvicorn app.main:app --reload # http://localhost:8000 Use the commands that actually work in your repo — no placeholders. Step 3 — Tests: the agent's feedback loop This is the most important section, because tests are how the agent checks its own work. Add: ## Test — all must pass before a change is done pytest ruff check . mypy app Now the agent

My wife tracks her meals, and I watched her type "buckwheat, boiled, 100 g" into a calorie app for the hundredth time. Search, scroll, pick the wrong entry, fix the grams. Every meal, every day. At some point it's easier to teach a vision model to look at the plate. So I built a Telegram bot. You send a photo of your food, it identifies the dishes, estimates portion weights, and replies with a card: calories, protein, fat, carbs. Text and voice work too ("2 eggs and a toast"). The borscht incident The first version was hilariously confident about wrong answers. Borscht — a red beet soup, if you've never met one — came back as "berry compote" (a sweet berry drink). Red liquid in a bowl, what else could it be? Adding more example dishes to the prompt made it worse : the model just got magnetized to whatever was on the list. A cod fillet became "syrniki" (cottage cheese pancakes) because syrniki were mentioned and both are pale and pan-fried. What actually fixed it was making the model read the serving context before naming anything: liquid served in a deep bowl with a spoon and sour cream is soup, not a drink. Flaky texture that separates in layers is fish, not pancakes. Fried items are never served floating in liquid. A short list of physical rules beat a long list of dishes. Portion estimation works the same way — the model reasons from plate size, cutlery, how full the bowl is. My wife has been checking its gram estimates against her kitchen scale for a week and it lands closer than either of us expected. Stack, briefly Python + aiogram, a vision LLM with structured JSON output (with a fallback parser for the days the model decides to wrap JSON in prose), Pillow for rendering the result cards. Photos are analyzed on the fly and never stored. Payments are Telegram Stars, so there's no app store, no signup, no card form — the whole onboarding is "send a photo". Yesterday I also wired up inline mode: type @SnapPlateBot in any chat, describe the food, and it counts rig

A gente sempre ouve falar que o sistema operacional impede que um processo veja a memória do outro ou que o programa fale diretamente com o hardware, mas normalmente não explicam o "como". Eu sempre achei isso meio mágico até que eu resolvi ir atrás da resposta, e é bem interessante. Vou me basear na arquitetura x86, mas é provável que outras arquiteturas sejam parecidas. O problema: a CPU Pra CPU não existe processo, kernel, sistema operacional. Existe só endereços de memória de onde ela lê a próxima instrução e executa. Se a CPU pode falar direto com a RAM, SSD, teclado, mouse, tela... O que me impede de escrever um programa pra ler suas senhas e tokens direto da RAM? Ou de ler arquivos e alterar arquivos sensíveis direto no SSD? Por outro lado, se o kernel fiscalizasse cada instrução que da CPU antes dela executar, isso seria extremamente lento... Outro problema: os interrupts Se a CPU só executasse sequencialmente, seu sistema poderia executar várias coisas e esquecer de checar se uma tecla foi apertada, se o mouse mexeu, etc... Então certos eventos interrompem o que quer que a CPU esteja fazendo para serem tratados assim que possível. Alguns exemplos de interrupt são: Teclas do teclado pressionadas ou soltas Botões e movimento do mouse Timers Operações de disco assíncronas Pacotes de rede recebidos/transmitidos Uma solução: rings Os processadores da arquitetura x86 tem o esquema de rings. Pense em rings como grau de limitação. Ring 0 significa limitação zero, ou seja, acesso a todas as instruções da CPU e consequentemente acesso total ao hardware e memória. O kernel roda em ring 0, ou kernel mode. O kernel assim que é carregado configura todos os interrupts handlers da CPU para executar o handler apropriado do kernel, em kernel mode, claro. Em ring 3 a CPU fica limitada e não pode fazer instruções consideradas privilegiadas. E obviamente em ring 3 a CPU não consegue se colocar em ring 0 sozinha, pois dessa forma qualquer programa conseguiria se pôr em ring 0. O

Half a year ago, I wanted to see for myself what can we currently have with local LLMs. I went down the rabbit hole, learned quite a lot in the process, and shared my results in an article . The results were pretty discouraging: even with 32 GB VRAM, the best models I could run were both too slow and too dumb. At the same time, what you could get for free from inference providers was actually decent - and much faster. I remember my conclusion: "Let's wait for the next generation of models, which looks very promising. If we can run something comparable to full-size Qwen3-Coder-480B locally, that would be year of the Linux Desktop age of fully capable local LLMs. And now this day has arrived. Models Half a year later, I'm revisiting this question. And this time, the whole situation has turned upside-down. Almost none of the providers still have free tier, and anything that's still free is barely good enough even for the simplest tasks. And is rate-limited all over. And on the local side, the next Qwen lineup is out. So, that's what I'm going to be looking at. Once again, I have two RX6800's, 16 GB each, and 64 GB RAM. On one hand, this is more VRAM than any "normal person" can have with one GPU - unless you've got something specifically for AI, like an unified-memory Mac or a DGX Spark. On the other hand, RX6800 is "pre-AI" - anything newer will have much better performance thanks to tensor processors. Qwen3.6-27B : This is a dense model, so basically you can't run it at all on anything less than 32 GB VRAM. It's the slowest one, but also the best one if you can run it. Its accuracy is claimed to be on par with Claude 4.5 Opus, and better than Qwen3.5-397B-A17B . This is what I've been waiting for. It runs reasonably fast on my setup, so it's very much usable both in terms of performance and accuracy. Qwen3.6-35B-A3B : This one is MoE, and it's pretty small, so it's the fastest one. It's good for anything that doesn't require too much (i.e. for agentic tasks that don'