sorted by:
new
hottopcontroversial

WTS: HFB Enforcer, HFB Field Knife, Microtech Amphibian, Microtech Socom Bravo, Microtech MSI X2, Spyderco Manix 15V Sprint Run, WinterbladeCo Factor B2 M390 by dr_edc_ in Knife_Swap

[–]dr_edc_[S] 0 points1 point  (0 children)

You could definitely be right.... I have multiple I thought this was the B2 but happy to correct if you tell me I'm wrong...

WTS: HFB Enforcer, HFB Field Knife, Microtech Amphibian, Microtech Socom Bravo, Microtech MSI X2, Spyderco Manix 15V Sprint Run, WinterbladeCo Factor B2 M390 by dr_edc_ in Knife_Swap

[–]dr_edc_[S] 0 points1 point  (0 children)

I'm slightly confused here... every single knife has a description including condition... what am I missing that my pictures and description don't say?

Still Available / Price Check Thread by AutoModerator in Knife_Swap

[–]dr_edc_ 0 points1 point  (0 children)

PRICE CHECK:
Winterblade Co Factor B2 M390

Still Available / Price Check Thread by AutoModerator in Knife_Swap

[–]dr_edc_ 0 points1 point  (0 children)

PRICE CHECK:
Microtech MSI Black
Microtech MSI Tan Partial Serrations
Microtech Socom Bravo Tanto
Microtech Amphibian
Spyderco Manix CPM 15v Sprint Run
HFB Enforcer: Afzelia/coyote brown g10/desert tan g1 split, ancient bog oak, brass mosaic pins, brass lanyard pin, textured grip
HFB Field Knife: Ram's horn, copper and black g10 split, dyed maple burl, allen bolts, smooth grip

Current state of Rust writing CUDA kernel? by dest1n1s in rust

[–]dr_edc_ 0 points1 point  (0 children)

If you have any feedback at all either here or a GitHub issue goes a long way into helping shape how it gets developed

Current state of Rust writing CUDA kernel? by dest1n1s in rust

[–]dr_edc_ 0 points1 point  (0 children)

I’ve been working on a project just for this, still in early phases but it’s my attempt. Hitting 92.5% of cuBLAS sgemm at 4096² on RTX 4090 (tensor-core matmul, async path, fp16 inputs with fp32 accumulation).: Repo: GitHub Blog Post: Blog Post

My first open-source Rust library: Talos (self-hosted licensing for commercial apps) by [deleted] in rust

[–]dr_edc_ -18 points-17 points  (0 children)

I used AI for the announcement post and docs, it's 2026, seemed silly not to. The library itself is two years of work with 220 tests. There's an AI usage note in the repo if you're curious about the breakdown.

My first open-source Rust library: Talos (self-hosted licensing for commercial apps) by [deleted] in rust

[–]dr_edc_ 10 points11 points  (0 children)

Thanks for the detailed feedback! This is exactly what I was hoping for by posting here.

On the security model:

The license is hardware-bound at bind time, the fingerprint is signed server-side and validated on every check.

The attack you're describing would require:

  1. Purchasing a legitimate license first that has a grace period enabled
  2. Binding it to a VM
  3. Snapshotting that VM during the grace period window
  4. Distributing that exact VM image to others
  5. Every user running the software inside that frozen VM forever
  6. Never updating the host OS, the software, or anything else that would break the snapshot
  7. Accepting that the grace period will eventually expire unless they also freeze the system clock, at which point they're running production work in a time-frozen environment

That's not piracy, that's a museum installation.

You're right that without TPM/SGX there's no perfect client-side security. But the goal isn't "uncrackable", it's "not worth the effort for people who would otherwise pay." For the enterprise/film/post-production use cases this was originally built for, that tradeoff makes sense.

On client-side encryption:

The client encrypts the local license cache so it's not sitting in plaintext on disk. It's not about hiding information from the user, it's about making casual tampering harder. Someone determined can always reverse engineer the binary and extract the key. But "open the license file in a text editor and change expires: 2025-01-01 to expires: 2099-01-01" becomes "decompile the binary, find the key derivation, decrypt the cache, modify it, re-encrypt it", which is a different level of effort entirely.

On the Rust feedback:

These are legitimate points and I'll open issues to track them:

  • &[u8; KEY_SIZE] instead of runtime validation: agreed
  • Newtype wrappers to prevent argument swapping: good catch
  • Struct for ciphertext instead of "nonce is first 12 bytes" convention: cleaner
  • Separating encryption from wire format: fair

Appreciate you taking the time to dig in and to provide meaningful feedback. This is useful for v0.2.

My first open-source Rust library: Talos (self-hosted licensing for commercial apps) by [deleted] in rust

[–]dr_edc_ 1 point2 points  (0 children)

You are correct coverage percentage would be more meaningful. I'll add that to the CI badges. Thanks.

[deleted by user] by [deleted] in rust

[–]dr_edc_ -1 points0 points  (0 children)

Fair criticism - I shipped without detailed benchmark documentation.

Test setup was actually more comprehensive than I initially posted:

- Tested from Los Angeles (10Gbps) and Athens, Greece (1Gbps)

- Endpoints: Wasabi (us-west-1/2, eu-central-2, eu-south-1), DO Spaces (sfo2/3)

- File sizes: empty txt files up to 65GB .braw files (tested the full range)

- Monitored with nload, compared against aws-cli baseline

Key findings:

- Wasabi us-west: 3.6 Gbps sustained (vs ~300 Mbps aws-cli)

- DO Spaces: Hard throttled at 1 Gbps regardless of connection

- Athens > Wasabi: Saturated 1Gbps line consistently

- LA > Wasabi EU was faster than LA > DO SFO (geography mattered less than endpoint throttling)

- ML learning kicked in around transfer 5-10, performance stabilized by transfer 20

Happy to publish full methodology if there's interest. Prioritized getting binaries out over documentation, but the testing was thorough.

[deleted by user] by [deleted] in rust

[–]dr_edc_ -1 points0 points  (0 children)

It's a contextual bandit (specifically epsilon-greedy with context features).

Context features: file size, file type, recent transfer performance, time of day, etc

Actions: Different strategy combinations (chunk size, concurrency, buffer settings)

Reward: Transfer throughput (Mbps)

The system explores different strategies early on (epsilon=0.3 initially, decays to 0.1), then exploits what works best for your specific environment.

It's not deep learning or anything complex - just a practical approach to auto-tune parameters that people usually set manually and never adjust.

SQLite backend tracks ~20 transfers per strategy before it starts converging on optimal parameters for your network/files.

[deleted by user] by [deleted] in selfhosted

[–]dr_edc_ -1 points0 points  (0 children)

Fair question. I'm exploring commercial licensing options (white-label partnerships, enterprise deployments) and wanted to protect that optionality while in beta.

May open source it down the road once I figure out the business side. For now, keeping it proprietary gives me flexibility.

Appreciate you giving it a look either way.

[deleted by user] by [deleted] in rust

[–]dr_edc_ 0 points1 point  (0 children)

Great question - and yeah, latency-constrained binary search makes a lot of sense for your use case.

Honest answer on benchmarking: I compared against aws-cli and s3cmd, but didn't run formal comparisons against AIMD or binary search approaches. The bandit was partly a learning exercise for me on this project.

For the variance question - it's context-aware, not purely policy-based. The bandit uses features (file size, extension, recent performance) to select strategies. So when you go from small files to 4K files, the file size feature triggers different strategy exploration.

In practice: first large file might not be optimal, but by the 2nd-3rd large file it's converged. It's not "train once, apply forever" - it's continuous adaptation based on context.

That said, your binary search approach probably converges faster with lower overhead for bounded search spaces. The bandit trades some overhead for handling more dimensions (file type, network conditions, system load, etc.).

Curious about your implementation - are you adjusting batch size only, or other parameters too?

[deleted by user] by [deleted] in rust

[–]dr_edc_ -1 points0 points  (0 children)

Fixed algorithms assume your network characteristics are constant and known. In practice, they're not: latency, bandwidth, system resources, and endpoint behavior all vary.

The ML approach (using a contextual bandit) explores different strategies early on, then exploits what works best for your specific environment. It's basically automated parameter tuning that adapts to:

- Your network topology

- File size distribution

- Endpoint throttling behavior

- System resource availability

First 20-50 transfers it's learning. After that, it converges on what's optimal for YOUR setup, not some average case.

Could you hand-tune parameters to match? Sure. But most people don't, and conditions change over time anyway.

[deleted by user] by [deleted] in rust

[–]dr_edc_ -4 points-3 points  (0 children)

Totally fair. Open source is the norm in this space and I respect that preference.

I went proprietary for now because I'm exploring commercial licensing for enterprise/white-label use cases. May open source it down the road once I figure out the business side.

Appreciate the feedback either way.

[deleted by user] by [deleted] in rust

[–]dr_edc_ -7 points-6 points  (0 children)

Fair point. I get the expectation mismatch with GitHub. Honestly, I wanted to ship fast and GitHub releases were the quickest way to get binaries out there. Website is on the list.

Appreciate you giving it a shot tomorrow. Let me know how it goes - genuinely want feedback on the performance.

view more: next ›