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

标签:#us

找到 1953 篇相关文章

AI 资讯

Why `rustdesk/rustdesk` Is Trending on GitHub: A Self-Hostable Remote Desktop Stack

RustDesk is gaining attention today with +84 GitHub stars , and the reason is straightforward: it provides an open-source remote desktop experience while allowing teams to control the infrastructure behind it. Unlike a client-only tool, RustDesk is built around a self-hosting model. The desktop client connects through a RustDesk ID server ( hbbs ) for rendezvous and a relay server ( hbbr ) when direct peer-to-peer connectivity is unavailable. This separation makes the architecture easier to reason about and gives operators more control over traffic and metadata. A quick server experiment can start with Docker: docker run -d \ --name rustdesk-hbbs \ --network host \ -v " $PWD /rustdesk-data:/root" \ rustdesk/rustdesk-server:latest \ hbbs docker run -d \ --name rustdesk-hbbr \ --network host \ -v " $PWD /rustdesk-data:/root" \ rustdesk/rustdesk-server:latest \ hbbr For production, configure the client with your server’s public key and hostname rather than relying on default discovery. Keep the relay and rendezvous ports documented, restrict administrative access, and store the generated keys in a protected location. The Rust implementation is a practical fit for a latency-sensitive desktop application: native binaries, low runtime overhead, and broad platform support. The trade-off is operational complexity. Self-hosting means handling updates, firewall rules, TLS or tunnel termination, backups, and monitoring yourself. Things to watch before production: Network design: Direct connections may fail behind strict NAT, forcing traffic through the relay and increasing bandwidth usage. Security controls: Treat the server key, access credentials, and client distribution process as sensitive infrastructure. Upgrade testing: Validate client/server compatibility in a staging environment before rolling out updates widely. For developers who want remote support without surrendering control of the entire connection path, RustDesk is a compelling open-source project to test in a p

2026-09-04 原文 →
AI 资讯

The unusually muted Tesla Cybercab launch

At a private, closed-door event in Austin, Texas today, Tesla officially launched its gilded car of the future. It's a huge milestone for Elon Musk, who has been hyping the imminent arrival of driverless cars for years and has bet the future of his company on AI, autonomous vehicles, and humanoid robots. It was an […]

2026-09-04 原文 →
AI 资讯

Don't claim a security boundary holds — demonstrate it

A system has to run a chunk of code you don't control —a plugin, a dependency, something generated— and you want to guarantee that code cannot touch the file system or spawn processes. Not that it "shouldn't": that it can't , mechanically. That's capability confinement, and it's one of the central problems of runtime security. Designing it and demonstrating it are two different things, and confusing them is expensive. A design is a claim You can write an impeccable document: "access to fs and to spawning processes is controlled like this, with these mechanisms, under this threat model". It's real and necessary work. But it's a claim . And the failure mode of a security boundary is that it looks like it holds until it doesn't —silent, invisible in tests, visible only when someone crosses it—. In security, an unverified claim has exactly the shape of a beautiful, wrong architecture. The design can assume that a module-loader hook fires at a point where it actually doesn't, and all the reasoning hanging off that is correct and worth nothing. The mechanisms exist, and there are several In Node, to name a concrete runtime, there are at least three layers, and they aren't interchangeable: The native permission model ( --permission , --allow-fs-read …), which cuts access to fs and to spawning processes at the whole-process level. SES / Hardened JavaScript (Compartments, lockdown() ), which confines what each module can import within the process. Module-loader interception , which controls what resolves when the code asks for something. Choosing well among them is the design. But choosing well doesn't prove the choice holds against the real dependency tree you're going to run. Demonstrate instead of claim The alternative to signing off a design is delivering a confinement harness : untrusted code that tries to reach the dangerous capability —open a file, spawn a process— against the real runtime and its real dependency tree, and a log that shows each attempt was blocked . O

2026-09-04 原文 →