标签：#RAM

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

After the browser transfers a file, the server may still scan, transcode, extract metadata, or generate previews. The interface needs status updates, but the most fashionable real-time transport is not automatically the most reliable choice for an event guest on a mobile browser. Start with the update contract Define states and transitions before choosing transport: accepted -> queued -> processing -> ready accepted -> rejected processing -> processing_error Every status response should include a monotonically increasing version or timestamp. The client can ignore events older than the state it already knows. Polling is a strong baseline HTTP polling works through proxies, resumes naturally after a page wake, and is easy to cache and rate-limit. Use adaptive intervals: one second just after acceptance, then back off to several seconds when processing takes longer. const delay = Math . min ( 8000 , 1000 * 2 ** slowChecks ); Add jitter when many guests finish at the same time. Stop when the state is terminal, the page is gone, or a server-provided retry time says to wait longer. SSE fits one-way progress Server-Sent Events are attractive when the server only pushes status. The browser reconnects with a last-event ID, and the wire format is simple. But mobile networks and some intermediaries silently kill idle connections. Send occasional heartbeats and treat reconnection as normal. The reconnect handler must fetch current state because events may have been missed beyond the server replay window. Do not keep one SSE stream per file. Subscribe by guest session or album and filter authorized upload IDs on the server. WebSockets add more responsibility WebSockets make sense when the client also sends frequent commands over the same channel or when a host moderation console needs many rapid updates. For a guest waiting on two files, they add connection authentication, heartbeat, reconnect, replay, and load-balancer complexity without much user benefit. Never rely on the so

The trust proxy setting is an important concept in backend development, especially when implementing rate-limiting in our APIs. But deciding its accurate value depends heavily on our deployment topology. When we deploy our application in production, the client may not talk directly to our backend. There may be 1 or more proxies in between who forward the request to the next proxy or the backend server. Those proxies can be Load balancers, API gateways, reverse proxy like nginx or any custom service. So effectively, our request has to do some 'hops' over these proxies to reach backend. When we implement rate limiting in app to prevent the DOS attack, we generally intend this rate limit on the basis of client IP address. And this works fine when client request reaches our backend directly. But when we have multi-hop architecture, the simple setup won't work as expected. Because the most recent IP will be of the proxy and not the client. So all the traffic coming from different users will be considered from the single client(our own proxy) and thus there will be false positives as the rate limiting will trigger much often. In this scenario, we must tell our backend to ignore these extra hops(i.e. to trust our proxies). This is done by specifying trust proxy. If there is 1 proxy between client-server we set trust proxy to 1; if there are 2, or more, we set it accordingly. This will ensure our express app skips(trusts) these IPs, and accurately figures out actual client IP. The originating IP address of client is identified from 'X-Forwarded-For' header by the express app. But setting trust proxy is not that straightforward. The numerical value for trust proxy will not work in every case. If there are different paths from which our request reaches backend, there is a chance that the number of proxies may be different in each path. For example - internal vs external traffic: External(public) traffic: (Client -> Web Application Firewall -> Load balancer -> Reverse Proxy ->

Welcome to Day 5! Today we shift from volatile, temporary in-memory variables to persistent storage and application durability . You will learn how to interact safely with your operating system's file system, read/write structured industry data patterns, handle real-world operational crashes gracefully, and keep execution timelines documented using professional logging architectures. 💾 1. File Handling & pathlib 📄 Python's pathlib module treats file paths as smart object structures instead of plain text strings. This avoids bugs caused by differing slash directions across operating systems (Windows uses \ , while Mac/Linux use / ). Reading ( "r" ): Loads file contents into memory. Writing ( "w" ): Erases any existing file contents and writes a fresh payload from scratch. Appending ( "a" ): Targets the end of a file, adding fresh text without overwriting existing contents. 🌱 Easy Starter Example from pathlib import Path # Create a path reference pointing to a file in the current workspace directory file_path = Path ( " notes.txt " ) # Write text cleanly to a file space file_path . write_text ( " Hello from Day 5! " ) # Read data straight back into a string variable content = file_path . read_text () print ( content ) # Output: Hello from Day 5! 🏛️ Real-World Example: Multi-Platform System Telemetry Appender from pathlib import Path from datetime import datetime def log_system_status ( status_message : str ) -> None : # Resolve home folder pathways seamlessly across Windows, Mac, or Linux systems target_dir = Path . home () / " app_workspace " / " telemetry " # Create the directory chain automatically if it doesn't exist yet target_dir . mkdir ( parents = True , exist_ok = True ) log_file = target_dir / " runtime_events.log " timestamp = datetime . now (). isoformat () # Secure stream channel using Python's standard file-open context manager with open ( log_file , mode = " a " , encoding = " utf-8 " ) as file : file . write ( f " [ { timestamp } ] STATUS: { status_mes

Event uploads fail differently from normal office uploads. A wedding guest may move between venue Wi-Fi and mobile data, lock the phone while a video is transferring, or close the browser as soon as the progress bar reaches 100%. Hundreds of devices can share one access point, and users rarely wait around to diagnose an error. The usual POST request plus optimistic success toast is not enough. A reliable browser flow needs a small protocol that distinguishes local preparation, network transfer, server acceptance, media processing, and final availability. This article describes a platform-neutral design for that protocol. The five states users actually experience Model each file as a durable state machine: selected -> preparing -> transferring -> accepted -> processing -> ready Add terminal or recoverable branches: preparing -> rejected_local transferring -> paused | retryable_error | expired accepted -> processing_error processing -> ready | processing_error The key distinction is between transferring and accepted . The browser may have sent every byte while the server has not yet committed the upload. Showing “done” at that boundary creates the most frustrating failure: the guest deletes the original, but the organizer never receives it. Give every file a client-generated identity Create an upload ID before the first network request. A UUID is sufficient when combined with the event identifier: const uploadId = crypto . randomUUID (); const uploadIntent = { uploadId , eventId , name : file . name , size : file . size , type : file . type , lastModified : file . lastModified , }; Send that identity when creating the server-side upload session. If the browser retries after a timeout, the server returns the existing session instead of creating a duplicate. This is idempotency at the workflow level. A guest can tap “retry” without having to understand whether the first request reached the server. Separate the control plane from file bytes Use a small JSON API for sessi

submitted by /u/Comfortable-Fan-580 [link] [留言]

Toss out a brick to lure a jade gem. — The 36 Stratagems, Throw Out a Brick to Get a...

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

How Bifrost Enterprise combines Data Access Control (DAC), Role Based Access Control (RBAC), Access Profiles, and Bifrost Edge to secure AI applications at scale. Artificial intelligence is quickly becoming part of every employee's workflow. Developers rely on coding assistants, customer support teams use AI powered chat applications, analysts generate reports with large language models, and organisations increasingly deploy AI agents connected to internal tools through the Model Context Protocol (MCP). While this rapid adoption improves productivity, it also introduces a significant governance challenge. It's no longer enough to decide who can log into an AI platform; you must also determine who can access specific AI resources, which models they can use, what they can spend, and which data they should even be able to see. This is where Bifrost Enterprise provides a comprehensive governance layer. By combining Role Based Access Control (RBAC), Data Access Control (DAC) , Access Profiles , and Bifrost Edge , organisations can secure AI workloads without slowing down innovation. Together, these capabilities create a governance framework that scales from small engineering teams to global enterprises and you can learn more about this in the documentation on GitHub . Why Enterprise AI Needs More Than Authentication Traditional enterprise applications typically answer two questions: Who is the user? What can that user do? Modern AI platforms introduce a third and equally important question: What information should this user actually be able to see? Imagine an organisation with several engineering teams working on independent AI products. Each team has its own prompts, routing rules, API budgets, virtual keys, observability data, and model configurations. If every developer can view every configuration simply because they have developer permissions, sensitive information can easily become exposed. This challenge becomes even more complicated when organisations begin deplo

Why giant AGENTS.md files may be wasting context, hurting maintainability, and making AI-assisted development harder to scale. A few years ago, for many developers, using AI for software development meant copying a small piece of code into a chat window. We would ask for a refactoring, copy the response back into the editor, run the tests ourselves, and return to the chat when something failed. Coding agents changed that workflow. Tools such as Codex, Claude Code, and others can now explore an entire repository, modify multiple files, execute commands, run tests, and iterate on failures. Coding agents turned code assistants into tools capable of executing multi-step software development tasks. But most repositories were not designed for this new kind of contributor. The repository became part of the agent's working context A coding agent needs much more than source code. It may need to understand: the project architecture; dependency boundaries; coding conventions; test strategy; build commands; local environment requirements; validation steps; security restrictions; the definition of done. A common solution is to place these instructions inside files such as AGENTS.md , CLAUDE.md , or other agent-specific configuration files. This works. I have been doing something similar in my own projects for a while. But as the repository grows, the instruction file grows with it. Eventually, a single file may contain thousands of lines covering unrelated concerns: Architecture Testing Environment setup Coding standards Infrastructure UI conventions Validation Release workflows Definition of done At that point, the file is no longer just a set of agent instructions. It has become an informal repository operating manual. The monolithic context problem A large AGENTS.md has an obvious advantage: the agent knows where to find it. But it also creates several problems. It is difficult for humans to navigate These files are not only for agents. Developers also need to read, review, m

Ken Thompson — คนที่เขียนระบบปฏิบัติการใน 3 สัปดาห์ ปี 1969 เคน ทอมป์สัน อายุ 26 เป็นวิศวกรที่ Bell Labs เขากับทีมเพิ่งเสียโปรเจกต์ Multics ซึ่งเป็นระบบปฏิบัติการที่ซับซ้อนเกินไปจนถูกยกเลิก Bell Labs ถอนตัว ทีมแตก โปรเจกต์ตาย เคนมีเวลาเหลือเฟือ และมี PDP-7 ซึ่งเป็นคอมพิวเตอร์เก่าที่แทบไม่มีใครใช้ ใน 3 สัปดาห์ เขาเขียน Unix kernel, shell, editor, และ assembler ขึ้นมาบน PDP-7 — ทั้งหมดเป็น assembly — ภาษา B ยังไม่เกิดตอนนั้น B ถูกสร้างขึ้นหลังจากนั้น — เพื่อใช้เขียน utility ต่าง ๆ แทน assembly — และนี่คือจุดเริ่มต้นของสายภาษา B → C → Go ภาษา B — เกิดหลัง Unix เวอร์ชันแรก Unix เวอร์ชันแรกสุด — สิงหาคม 1969 — เป็น assembly ล้วน หลังจากนั้นไม่นาน Ken ก็เริ่มสร้าง B — โดยตัดทอนมาจาก BCPL — เพื่อให้มีภาษาระดับสูงไว้เขียน tools โดยไม่ต้องใช้ assembly ทั้งหมด B มาจาก BCPL (Basic Combined Programming Language) ซึ่งพัฒนาโดย Martin Richards ที่ Cambridge ในปี 1966 BCPL เป็นภาษาที่ไม่มี type — ทุกอย่างคือ word — และออกแบบมาให้ compiler พกพาง่าย Ken เอา BCPL มาตัดทุกอย่างที่ไม่จำเป็นออก — จนเหลือภาษาเล็กมากที่ทำงานได้บน PDP-7 ซึ่งมี RAM แค่ 4K words PDP-7 Assembly → Unix v1 (1969, 3 สัปดาห์) ↓ BCPL (Richards, 1966) ↓ ตัด feature, ลดขนาด B (Thompson, 1969-1970) ↓ ใช้ rewrite Unix utilities (ไม่ใช่ kernel) ↓ ↓ เพิ่ม type system, struct, portability C (Ritchie, 1972) ↓ Unix v4 rewrite ด้วย C (1973) B ไม่มี type system ไม่มีโครงสร้างข้อมูล มีแค่ word — เหมือนกับว่าเป็น BCPL เวอร์ชัน minimal B ถูกใช้เขียน shell, utilities, และ tools ต่าง ๆ ของ Unix — แต่ kernel ยังเป็น assembly อยู่ จนกระทั่ง Dennis Ritchie สร้าง C ขึ้นมาในปี 1972 ทำไมต้อง B PDP-7 มี assembly แต่นั่นไม่ใช่เหตุผลที่ดีพอที่จะใช้มัน Ken ไม่เชื่อในการเขียน OS ด้วย assembly ทั้งระบบ — assembly เร็วแต่เขียนช้า แก้ยาก พกพาไม่ได้ การใช้ภาษาระดับสูง (แม้จะสูงนิดเดียวแบบ B) ทำให้: เขียน shell, utilities เร็วขึ้นมาก แก้ไขง่าย — ไม่ต้องเขียนใหม่เวลาย้ายเครื่อง ใช้คนน้อยลง — Unix version แรกเขียนโดย 2 คน จาก B → C → Unix → ทุกอย่าง เมื่อทีมได้ PDP-11 ซึ่งเป็นเครื่องที่ใหญ่กว่า — B เริ่มมีปัญหา PDP-11 มี byte-addressing แต่ B ออกแบ

I have released version 2026-07-11 of Seed7 . Seed7 is about portability , maintainability , performance and memory safety . There is an automatic memory management without a garbage collection process (which might stop the world). The templates / generics don't need syntax with angle brackets. Seed7 is an extensible programming language. The syntax and semantics of the language is not hard-coded in the compiler but defined in libraries. Seed7 checks for integer overflow . You either get the correct result or an OVERFLOW_ERROR is raised. Unlike Java Seed7 compiles to machine code ahead of time (GRAAL works ahead of time but it struggles with reflection). Unlike Java Seed7 operators can be overloaded . Unlike C, C++, Go, Zig, Odin, Nim and C3 Seed7 is a memory safe language. The standard libraries cover many application areas. Example programs are: make7 , bas7 , pv7 , tar7 , ftp7 , comanche and many more. This release consists of 1029 commits from several contributors (thanks to them). Notable changes in this release are: Many improvements have been triggered by the Seed7 community. Support for the PCX image file format has been added and the support for BMP , TGA , JPEG and TIFF has been improved. Protections against stack overflow and shell injection have been added. Checks for the result and the parameters of primitive actions have been added. Several database drivers have been improved. A detailed change log can be found at r/seed7 or GitHub . This release is available at GitHub and SF . There is also a Seed7 installer for windows , which downloads the newest version from GitHub and SF. The Seed7 Homepage is now at https://seed7.net . There is a demo page with Seed7 programs compiled to JavaScript/WebAssemly. Please let me know what you think, and consider starring the project on GitHub, thanks! submitted by /u/ThomasMertes [link] [留言]

Introduction A Continuation of Shadow SCADA Terminal Velocity begins where Shadow SCADA left off — at the edge where digital audits meet the physical world. In the previous article, we explored how hidden infrastructures reveal themselves through aerial recon, magnetic anomalies, and environmental signals. Now we move deeper: into the physics of sensing, the light‑based pathways of diodes and photodiodes, and the high‑spec tools that transform invisible signals into readable intelligence. Modern audits are no longer limited to dashboards and logs. They extend into light, magnetic fields, environmental distortions, and sensor‑level truth — domains that traditional processes never touch. Section 1 – Diodes and Photodiodes: The First Gate of Physical Signals In modern audits, everything starts at the physical layer — where electricity and light move before any software or dashboard exists. Two tiny components sit at that gate: diodes and photodiodes. They look similar, but they do very different jobs. What is a diode? · One‑way valve for electricity: A diode lets electric current pass in one direction only, like a one‑way street. · Why this matters for security: Diodes are used to make sure information can leave a system but cannot come back in through the same path (for example, in SCADA or critical networks). · Simple image: Think of a diode as a door that only opens outward. You can exit, but nobody can enter through that door. What is a photodiode? · Sensor for light: A photodiode doesn’t control current—it detects light and turns that light into an electrical signal. · Where it’s used: In cameras, light sensors, security systems, and tools that “listen” to the environment through light. · Simple image: Think of a photodiode as a tiny eye that sees light and tells the system, “Something is shining here.” The key difference (in one sentence) · Diode = controls flow. · Photodiode = senses light. Diodes are about blocking or allowing. Photodiodes are about seeing and

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

FCC chair has been gifted at least $63,000 worth of tickets by CBS or its parent company.

I wanted to make this post because man...tables are way harder than they look. I documented my 1 year journey of optimizations on a stupid table for my Database GUI. I made everything from scratch like an idiot thinking it'd be easy but oh boy was I wrong... The article goes over all the optimizations I made to make my table render data smoothly without lagging. It goes from what data structures I used and the rendering optimizations I did. I used MongoDB Compass as a baseline since they use AG-Grid for their table and I'm pretty happy that my table feels way smoother than that (In my own testing)! But yeah, I never realized that there would be so much depth in making a performant table. PS. I decided not to use AG-Grid because there were a lot of customizations that I needed to do. I wanted column expansions ( if a field as an object or an array it would open columns to the right of it ). I also wanted an embedded text search where you could search for text within non visible columns (because they were in objects or arrays ) and AG Grid didn't really support that behavior so ..yeah. Anyways have a good read! submitted by /u/Fun-Chicken6946 [link] [留言]

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

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

The label that gets the sequence backwards "AI-first" has become a branding exercise....

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