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

标签：#Rust

找到 277 篇相关文章

AI 资讯

ExtendDB: Open Source Amazon DynamoDB Compatible Adapter with Pluggable Storage Backends

AWS recently announced ExtendDB, a DynamoDB-compatible adapter that lets developers use the DynamoDB API with different storage backends, starting with PostgreSQL. The project supports existing SDKs and tools without modification, giving teams greater flexibility to run DynamoDB-style workloads outside of native DynamoDB while maintaining compatibility with current applications and workflows. By Renato Losio

2026-06-07 原文 →
AI 资讯

Building a SQL Lexer in Rust: Why I Replaced `Vec ` with `&str` and `Ident(String)` with Spans

I've been building a database engine from scratch in Rust, and I recently finished the lexer. The lexer itself wasn't the most interesting part. What I found more valuable was how my design evolved as I learned more about Rust and how compilers and database systems are typically implemented. My First Approach When I started, I stored the input as a Vec<char> . It felt straightforward because I could access characters directly without worrying about UTF-8 boundaries. I also represented identifiers like this: Ident ( String ) At first glance, this seems perfectly reasonable. Every identifier token carries its own text, making it easy for the parser to consume. The Problem As the lexer grew, I started asking myself a simple question: The identifier already exists in the original SQL query. Why am I allocating another string and copying the same data into every token? For a query like: SELECT username , email FROM users ; the source text already contains: username email users Creating separate String allocations for each identifier means duplicating data that already exists. I also learned an important detail about Rust enums. The size of an enum is influenced by its largest variant. Once variants start carrying additional data, every token instance becomes larger than it otherwise needs to be. Moving to a Span-Based Design Instead of storing identifier text directly inside tokens, I switched to storing only the token kind: Ident along with source location information: Span { start , end , line , column , } Now the token only answers two questions: What is this token? Where did it come from? If the parser needs the actual identifier text, it can recover it directly from the original SQL source using the stored byte range. Replacing Vec<char> with &str The second design change was moving away from: Vec < char > and operating directly on: & str using lifetimes. Instead of creating another collection containing the entire input, the lexer now walks over borrowed source tex

2026-06-06 原文 →
AI 资讯

What if weather observations could participate in blockchain security?

We are exploring an experimental blockchain mechanism called "Proof of Weather" In the world of blockchain, various methods are used to achieve network consensus. The most well-known is Bitcoin’s Proof of Work (PoW). While PoW is an excellent mechanism, it has one major drawback. It consumes an enormous amount of electricity. At one point, I found myself wondering: Does blockchain really require such vast computational resources? Isn’t there something else that’s needed? This led to the creation of Dawn, the experimental cryptocurrency project I am developing, and an experimental blockchain mechanism called Proof of Weather. In this article, I will discuss: Why I decided to use weather How Proof of Weather works Security considerations Implementation in Rust How Does Proof of Work Work? Proof of Work is often explained as a mechanism where computers compete against each other in computational tasks. However, one important property of PoW is that it produces outcomes that are difficult to predict in advance. Miners repeatedly perform massive amounts of hash calculations, and only those who happen to meet the conditions can generate a block. This unpredictability plays a role in determining who can produce the next block. However, this process consumes enormous amounts of electricity worldwide. So I wondered: Aren’t there already phenomena in nature that are difficult to predict? Why Weather? Proof of Weather utilizes weather data as that unpredictable element. Of course, weather forecasts exist. However, Temperatures several days in the future Atmospheric pressure at specific locations Precipitation Wind speed and other factors cannot be predicted with absolute certainty. In particular, when combining observations from multiple locations, it becomes even more difficult to accurately calculate future values in advance. In other words, meteorological observations have the potential to be used as A real-world information source where future values cannot be fully predic

2026-06-06 原文 →
AI 资讯

Analysis of Mo Gawdat and Marina Mogilko’s Conversation About the Future of AI, Startups, Education, and the Labor Market

AI Does Not Cancel Reality I watched the conversation between Mo Gawdat and Marina Mogilko about the future of AI. The conversation is strong. It contains important ideas, but it also contains many claims that sound large in scale, although on closer inspection they rely on very broad generalizations. AI is indeed changing the labor market, education, startups, content, hiring, and ways of thinking. But it does not cancel money, connections, trust, the human vector, creativity, necessity, morality, or people’s ability to adapt. Video on YouTube AI in hiring: automation amplifies chaos Many people have entered the job market. Companies receive huge volumes of resumes. HR departments cannot handle the volume. It is natural that part of the selection process is moving to AI. But there is a serious problem here. Candidates are also starting to play against AI. Resumes are adjusted to vacancies. Cover letters are assembled around keywords. Profiles become optimized for the filter, not for real work. In such a system, the best specialist does not necessarily pass. Often, the person who understood the selection mechanism better passes. The result: the picture becomes cleaner, while the quality of the decision becomes lower. The company gets not the strongest candidate, but the candidate who matched the algorithm best. This leads to lower hiring quality, lower productivity, and slower development. “I built a startup in six weeks”: a product is not a startup The conversation includes the idea that an AI startup would once have taken years and hundreds of engineers, and now it can be built in weeks. Technically, this is true. Prototypes are now built faster. Small teams have powerful tools. One person can now do more than a group could do before. But two different things are mixed here. Building a product faster has become real. Building a startup faster has become real only when resources are present. A startup is not only code. A startup is money, connections, trust, reputa

2026-06-06 原文 →
AI 资讯

I Consolidated My Entire Developer Homelab onto One Machine — Here's the Full Stack

I recently rebuilt my homelab from scratch. The goal was simple: one machine, everything containerised, zero exposed ports, GPU-accelerated local AI, and a fully automated backup setup. No cloud subscriptions for the tools I use every day. This is the full technical breakdown — what I'm running, how it's wired together, and the hard-won fixes that cost me hours so you don't have to repeat them. What I'm Running Eight services, 26 containers, one machine: Service Purpose Portainer Docker management UI Uptime Kuma Service monitoring (7 monitors) NocoDB Self-hosted Airtable — CRM & leads n8n Workflow automation Open WebUI Local AI chat interface Ollama Local LLM inference (GPU) AFF!NE Collaborative docs & whiteboards Plane Project management (roadmaps, sprints) Duplicati Encrypted daily backups Cloudflare Tunnel Zero Trust secure access — no open router ports All external-facing services sit behind Cloudflare Zero Trust with email OTP. No passwords to manage, no VPN clients — Cloudflare handles authentication at the edge. Architecture ┌──────────────────────────────────┐ │ Cloudflare Edge (Zero Trust) │ │ *.yourdomain.com — email OTP │ └──────────────┬───────────────────┘ │ HTTPS ┌──────────────▼───────────────────┐ │ Ubuntu Machine │ │ │ │ cloudflared (outbound tunnel) │ │ │ │ │ ┌─────▼────────────────────┐ │ │ │ homelab-net (bridge) │ │ │ │ │ │ │ │ portainer uptime-kuma │ │ │ │ nocodb n8n │ │ │ │ open-webui affine │ │ │ │ plane-* duplicati │ │ │ │ ollama (GPU passthrough) │ │ │ └───────────────────────────┘ │ └───────────────────────────────────┘ Everything runs on a shared Docker bridge network ( homelab-net ). The cloudflared container maintains an outbound-only encrypted tunnel — no inbound ports open on the router at all. Ollama runs in Docker with NVIDIA GPU passthrough. The AI model inference happens on the GPU, leaving CPU headroom for all other services. Prerequisites Ubuntu 24.04 LTS Docker Engine + Compose v2 NVIDIA GPU with driver 535+ NVIDIA Container Too

2026-06-05 原文 →
AI 资讯

QuickLook Integration in a Tauri App — Native macOS File Preview

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion. HiyokoKit's MTP file manager includes QuickLook preview. Press Space, see the file. Native macOS behavior in a Tauri app. Here's how it works — and why it's worth doing. What QuickLook Is QuickLook is macOS's built-in file preview system. Press Space on any file in Finder — that's QuickLook. It handles images, PDFs, videos, and documents without opening separate apps. For a file manager, QuickLook preview is table stakes on macOS. Users expect it. If it's missing, the app feels unfinished. Triggering QuickLook from Rust The qlmanage command-line tool can trigger QuickLook from any process: use std :: process :: Command ; #[tauri::command] async fn preview_file ( file_path : String ) -> Result < (), AppError > { Command :: new ( "qlmanage" ) .args ([ "-p" , & file_path ]) .spawn () .map_err (| e | AppError :: Preview ( e .to_string ())) ? ; Ok (()) } qlmanage -p opens a native QuickLook preview window for the specified path. That's it on the Rust side for local files. For MTP Files: Download First, Preview, Cleanup Files on an Android device don't have a local path — they live on the device over MTP. The flow is: download to a temp file → preview → clean up. #[tauri::command] async fn preview_mtp_file ( device_path : String , filename : String , ) -> Result < (), AppError > { // Download to temp let temp_path = std :: env :: temp_dir () .join ( & filename ); download_from_device ( & device_path , & temp_path ) .await ? ; // Open QuickLook Command :: new ( "qlmanage" ) .args ([ "-p" , temp_path .to_str () .unwrap ()]) .spawn () ? ; // Schedule cleanup after delay let temp_clone = temp_path .clone (); tokio :: spawn ( async move { tokio :: time :: sleep ( Duration :: from_secs ( 30 )) .await ; std :: fs :: remove_file ( temp_clone ) .ok (); }); Ok (()) } 30 seconds gives the user time to view before cleanup. For large files (RAW photos, videos), y

2026-06-05 原文 →
← 上一页 下一页 →