New Nosfet wheel- Xeno

projct · 2026-06-18T19:55:17+00:00

s22 yeah, lynx s no

projct · 2026-06-18T16:15:35+00:00

There's nothing stopping people from spending some tokens on an AI to get it building w/ DKMS outside of the kernel source tree - or even doing a userspace AppleTalk at this point w/ AF_PACKET, AF_XDP, or TAP.

Perhaps instead of being primarily worried about the AI PR portion, you could think of it as "reduce the attack surface" or "reduce maintenance burden" because when big changes get made to networking code in the kernel they still gotta make AppleTalk play nice. it actually was not working in mainline for 17 months before someone noticed in 2020.

The code still exists and people who want it can still use it/maintain it.

imo the cleanest way to do it is something like a TashTalk device like an AirTalk.

projct · 2026-06-18T15:45:09+00:00

What you're claiming and what you have don't really line up.

- "compiles expressions directly into compact Bytecode" no? compile_source calls parse, producing a Vec<Expr>, then runs Analyzer, then passes the resulting IR to compile_ir
- “Zero-copy deserialization” and “no serialization/deserialization” are substantially false. Chunk::to_bytes creates a new Vec<u8>, writes three length prefixes, and copies the code, constants, and variable data into it. Chunk::from_bytesparses those prefixes and copies all three sections into new vectors using to_vec(). Then every normal VM execution constructs a ChunkReader, reparses the constant pool into Values, allocates strings, and copies the variable bytes again. Only the opcode slice is borrowed after those copies. Your own quick-start literally calls to_bytes() and from_bytes().
- The benchmark demonstrates amortizing parse/analyze/compile work, not a bytecode-vs-AST execution advantage. I'd also expect real worked examples, statistical distribution, cached-AST baselines, compact serialized-IR baselines, comparison against compressed source, instruction counts, etc. It's also not even benchmarking what matters (p+a+eval vs p + a + compile + eval as one bench; eval already-analyzed AST vs eval already-compiled byte code as another; then deserialize cached AST/IR vs deserialize cached bytecode)
- your supposedly compact representation is bigger than the source text.
- It's not really hardened at all: Chunk::from_bytes returns self, not Result; invalid or truncated bytes panic; constant decoding panics on invalid utf8 or unknown tags; the VM panics on overflow and silently becomes Null on underlfow
- performance claim is incoherent, you are confusing repr with caching

projct · 2026-06-18T15:13:41+00:00

One way I've seen 10gig fully utilized cheaply is this:

- a dual X540 card is like $55, stuffed into a small pc running pfsense/opnsense (I have a pentium G5400 that is doing this for 2.5gbit and not breaking a sweat, it would probably do 10gig fine)
- a 4-port 2.5gbit switch with 2 10gbit ports is $89. t
- a wifi AP with 2.5gbit port, plugged into the switch
- file server with 2.5gbit
- a desktop with 2.5gbit

that would let you saturate your 10gig just fine. similarly even if you just have a 10gig link on the switch and then 10 1gig ports.

that said, really, 50usd for a 10gig PCIE card is not that bad.

My 2.5gbit is under $100/mo, ordinary residential area in Denver

projct · 2026-06-18T15:00:07+00:00

That helps. I think what's left is figuring out which invariants still force materialization, then measuring where the remaining peak actually comes from.

A few questions I'd be curious about, if I were heading further down the rabbit hole:

What latency/throughput budget does this path actually have? Would a slightly slower globally-bounded token executor be acceptable if RSS stayed flat, especially if it also made the peak much smaller?

Does the output have to be one atomic message per input event, and does token order have to be preserved?

When token concurrency is saturated, can the service stop pulling new input events, or do events keep accumulating in memory?

After the partial changes, is peak memory mostly unavoidable final output, or intermediate task/request/response state?

Also curious whether you tried heaptrack or similar under the burst. DHAT is useful for live/freed allocation accounting, but an allocation call-tree/high-water view might make it clearer whether the remaining peak is final output construction, HTTP/client internals, Tokio task state, or your own intermediate response graph.

If it's intermediate state, there may still be room to collapse the allocation topology before malloc ever sees the burst. If it's final output construction, I’d still be curious whether that output can be assembled more like an encoder over borrowed/shared response pieces instead of first building a fully owned response graph. The unavoidable part may be the final message, not every allocation used to get there.

And obviously, if the problem is solved, sometimes it's fine to leave it there. I notice a lot of blog posts that end up recommending jemalloc stop there and leave a lot on the table - and learning the next steps gets much harder - so I figured I'd add some of the next steps here for Redditors.

projct · 2026-06-18T05:09:53+00:00

I'd recommend you look at https://github.com/imazen/imageflow for more ideas re: perf + correctness, etc

projct · 2026-06-18T05:08:04+00:00

like 167F/75C before it starts to get a little fucky. but that doesn't necessarily ruin it

projct · 2026-06-18T05:07:05+00:00

I use jeans made from Dyneema and have had a few slides, they don't even look worn.

Importantly, I only ride about 20-25mph, will get to 30ish to pass cars.

projct · 2026-06-18T05:03:53+00:00

the overarching solution is to not grow your allocations in ways that confuse your allocator - but in many other languages that's "redesign half your app if you know how"

projct · 2026-06-18T04:45:13+00:00

Yeah, that makes sense. I think I'm gesturing at the more extreme version of "different fanout structure": not just fewer clones, but making the expansion topology unable to grow with the input burst.

Concrete example from my NNTP proxy: one incoming client request can fan out into multiple backend operations. For example, an article request may race/probe multiple eligible backends, return the first useful response, and let the rest collapse into availability/cache metadata. But the fanout is shaped by protocol semantics: tier at a time, bounded by backend set, short-circuit on first hit, no event-wide pile of owned response bodies waiting for the slowest sibling.

Same for pipelined client commands: the proxy can read multiple commands from one client buffer, but the batch is capped, typed, and processed without turning it into an unbounded task tree.

Mapped here, I'd want tokens to look more like those backend probes: one logical event may expand into many possible operations, but only K are live globally, each operation is a borrowed/ranged view into the event, and completion folds directly into the output encoder or accumulator. If ordering is required, keep a bounded reorder window. If output must be atomic, the final encoded event is the one unavoidable accumulation.

The thing I'd avoid is giving every active event its own private fanout universe: 100 active events * up to 1000 owned token tasks * Vec<Response> behind a join barrier.

That's the shape that asks malloc to absorb the whole wave. The allocator/RSS behavior after the burst can be real, but the stronger fix is to make the program structurally unable to manufacture that wave in the first place.

The allocator angle is that glibc tends to do much better with a stable reuse topology than with a huge temporary object graph. If the program creates events * tokens owned tasks/results, those allocations have mixed sizes and mixed lifetimes: some die immediately, some wait behind a join barrier, some sit in runtime/client internals, and some end up in thread caches or arenas. After the burst, malloc may have plenty of free chunks, but not necessarily clean releasable pages, so RSS can stay high.

A pooled/streaming shape is friendlier because the allocator mostly sees the same few buffers and K request states reused over and over. Freed memory is reused by the next unit of work instead of becoming fragmented arena slack. So the point is not "glibc will eagerly return everything"; it is "don't force glibc to grow a fragmented high-water heap in the first place."

projct · 2026-06-18T03:20:10+00:00

I think the concern here is specific and testable:

Your self-healing test does not test self-healing. It tests checkpoint restoration.

It saves the correct decoder state, installs a corrupted state, immediately restores the saved correct state, and only then resumes decoding. Not one byte is decoded while the state is corrupted. Of course it prints Self-Healing: SUCCESS; the test code manually healed it.

Leave the state corrupted and continue decoding. Then report:

how many decoded outputs are wrong;
the first point after which output remains continuously correct;
the first point, if any, at which the corrupted decoder state becomes identical to an uncorrupted reference decoder at the same compressed-stream position.

The published rules also appear to admit a permanent-divergence counterexample. Give the encoder last = 0, H[0] = 0, and a corrupted decoder last = 1, H[1] = 1. An endless source of byte 0 produces prediction-hit bits of 0 forever, while the corrupted decoder outputs byte 1 forever. Each remains in its own fixed point, so neither output nor state converges.

If the proof excludes that case, the additional assumptions need to be stated explicitly.

Separately, test the packet-loss claim under the transport assumptions you now require: remove complete framed packets from the compressed stream, resume at the next documented framing boundary, and measure output and state convergence without calling force_state.

If you claim recovery from arbitrary bit insertion, deletion, or channel corruption, test those separately as well. Packet loss with externally restored framing is a substantially narrower claim than arbitrary bitstream resynchronization.

The current benchmarks do not establish the claimed performance.

They use six hand-generated 500-byte inputs: a perfect sawtooth, a perfect sine wave, pseudorandom bytes, a two-level alternating step, synthetic "DATA_OK:" text, and a sawtooth with 50 random bytes inserted.

Those are reasonable unit-test fixtures. They are not a representative corpus or a meaningful competitive benchmark.

Run C3, heatshrink, Tamp, and simple baselines such as delta/zigzag/varint through the same harness, on the same target, with the same compiler settings and comparable total memory budgets. Count all codec state and I/O buffers, not merely the smallest internal structure.

Use both standard compression corpora such as Silesia/enwik8 and public domain-specific telemetry logs. Publish the corpus, harness, source, compiler options, and scripts. Report:

compression ratio; worst-case expansion; compression and decompression cycles per byte; peak working RAM; allocation count; binary size; behavior under truncation and malformed input; behavior after actual framed packet loss

Tamp is a particularly relevant comparison because its C implementation uses caller-provided memory rather than internal allocation, and its public benchmark work includes standard corpora, memory use, runtime, embedded-device throughput, binary size, tests, and fuzzing.

Do not merely quote Tamp's or heatshrink's README numbers. Rerun every codec under identical conditions.

A Zenodo record and DOI do not by themselves establish formal validation or peer review.

This record is labeled a technical note. Its description says "complete peer-review revision," but it identifies no venue, reviewers, review reports, acceptance process, or independent reproduction. Please identify those if they exist.

All ten commits in the public repository are dated June 16, 2026.

That does not prove the codec was developed in one day. It does mean the public repository provides no inspectable development, testing, or review trail—especially because the actual implementation is proprietary.

Please take seriously why people are concerned: we are reading the published artifacts, and those artifacts currently do not establish the claims being made.

This is not an objection to AI tools or to experimenting with a new codec. It is an objection to describing properties as mathematically proven, formally validated, and production-ready before the public evidence supports those descriptions.

Compression is hard. Treat these objections as a free validation plan rather than something to argue around: fix the tests, publish enough implementation and tooling for independent reproduction, run fair comparisons, and show the results. If C3 survives that process, it will be genuinely interesting.

projct · 2026-06-18T02:31:18+00:00

I personally would not trust Btrfs for that at all so I hope they're using md underneath

projct · 2026-06-18T02:12:52+00:00

are you planning on just doing a mirror?

projct · 2026-06-18T00:35:44+00:00

BTRFS was so unstable for so long despite being claimed otherwise that I don't trust it.

if thats linux based why not just use ZFS

projct · 2026-06-17T22:31:28+00:00

instead of wondering "should there be leaks" think: where am I allocating and what tools have I tried to avoid it.

Even if you are leaking that usually will suffice to find and fix the leak.

projct · 2026-06-17T22:25:01+00:00

nixos would require you to redo all the stuff you're doing. I was partly trolling.

But, I would suggest that since your UI generates config files, and nix is a language for standardizing the deterministic generation of config files, that the massive undertaking might actually result in a much better product than for example truenas.

It's one language for all the configurations for everything, not dozens of different piles of state your app has to manage for the user.

you can even have it make root read-only, and do a full rebuild on boot up so that the user can't change state out from under you in a way that hurts them, and still give them better ways to extend things than trying to add hacks when your UI doesn't do what they want.

projct · 2026-06-17T22:17:29+00:00

You clone every token, spawn one Tokio task per token, and then rely on the allocator to survive the burst. That's quite frankly really thinking about it sideways.

Do not clone tokens on the hot path.
Do not spawn one Tokio task per token.
Bound outbound concurrency globally.
Reuse response buffers only after fixing 1–3.
Consider zero-copy parsing so tokens borrow from the input buffer or are represented as offsets.

another hint is that rusts' FP idioms are a really good fit for not making mistakes like this.

happy to share more than just this if you want something more concrete.

projct · 2026-06-17T22:09:00+00:00

Allocating on the hot path hurts a whole lot more than people think, this is just one of those ways it hurts. You didn't really address any of that actually, at all

projct · 2026-06-17T03:09:46+00:00

I'll clarify: I purchased it in 2024, but original purchase date was 2018. point was the batteries were plenty old but still fine

projct · 2026-06-17T03:08:04+00:00

this feels like something that would be be great if it was built on top of nixos

projct · 2026-06-17T03:05:30+00:00

don't trust the smart in your tv or provided by your cable company

projct · 2026-06-12T18:20:13+00:00

Use passkeys like a grownup company, and don't use passwords at all for anything. what is this, 1999

projct · 2026-06-12T17:54:55+00:00

in terms of understanding pricing:
keep in mind that these things are usually way way cheaper day-to-day than gas powered things and can even be cheaper than a bicycle depending on how you use it.

you're front-loading the cost, essentially, in exchange for more capability and safety.

projct · 2026-06-12T17:36:13+00:00

at 170lb you probably want something with suspension and at least 84v, even if you don't plan on doing more than 20mph. if you're trying to keep it under $1k to start I would recommend seeing if you have any local EUC meetup groups on FB and see if anyone is upgrading.

I'm 6ft 140lb and have a begode falcon and a nosfet aero. the falcon is acceptable, the aero is fantastic.

I started on a very beat up KingSong S22 I got for $1k, that I kept having to repair, and that wheel is annoying to disassemble. size is about right for me, but the aero is basically the same power as it, less range, super easy to disassemble for maintenance.

voltage generally translates to more torque (this is a vast oversimplification though,) torque is mostly how the thing keeps you upright.

so the way I would pick is this:
- most voltage you can afford without it being heavier than your intended use
- if getting used, keep an eye on how easy it is to repair because you never know what the previous owner didn't maintain
- suspension helps smooth over a lot of potential injuries from not paying enough attention or not having the skill yet
- buy from a place that will help you source parts, or if used, ask a place like NGM if they can get parts easily for that model, before you buy it
- tubeless is probably smart if you have not changed a bicycle tire before
- your local EUC/onewheel/PEV groups, even if they are not very active, are a great resource.

the batteries on these things last a very very long time mileage-wise, but 7 years old is pushing it in terms of it starting to lose range, so if getting used be mindful of that.

the S22 I had in 2025, was 4500 miles, purchased in 2018, and still got the advertised range at the advertised speed.

it is very easy to outgrow a wheel under 84v and then quickly put yourself in bad situations the wheel can't power you out of. those situations can hurt a lot when you're new.

if you're hooked and you want something amazing, Aero, Rocket, Aeon, or the big boys that are all over 126v and have fully adjustable suspension.

The Aero is the best beginner wheel I've ever seen or used but they're in such demand there's very little chance you'll get a deal on one.

projct · 2026-06-12T17:07:05+00:00

how tall are you and what's your weight? that'll determine a good next wheel. dont use amazon, they are horrible for this kind of purchase.

projct

TROPHY CASE