Hacker Newsnew | past | comments | ask | show | jobs | submit | thomasjb's commentslogin


The temperature stability looks fantastic, but it has a voltage coefficient for capacitance which is worse than film caps.

From datasheet:

> Voltage <-0.1%/Volt

That is significant: over just a 10V swing, it could be as high as 1%.

For a plain old polyester film cap, this is something like ±0.0001%/Volt, IIRC.

If you have an audio signal swinging over a -12 to +12 V range being coupled through a thing like this, there will be measurable distortion arising from ~ 0.1%/V variations in capacitance.

Not that you would want to necessarily do that in the first place, since this thing has an 11V breakdown voltage, nothing to write Mom home about.

There is no one-cap-fits-all; right cap type for the right job.


I'm no expert but the doc says 73KHz-220GHz, this isn't intended for low frequency audio circuits


All silicon capacitors are relatively expensive, they're specialty parts that generally go into expensive things (mmWave airport scanners, optical backhaul, etc).


Did they build 5,000 airport scanners at once? MOQ is brutal!


One scanner has way more than one channel…


Consider the device that they gonna be placed in, it's basically nothing.


A single 6MHz channel at the top end of UHF band would be enough to implement a universal cellular telephony service - simple calls and texts - at very low cost if phones had modems for it. I think that would be the better use of spectrum.


RF Channels 38-83 have all been taken from (US) TV since the 80s. Mostly used for mobile phones.

rf 70+ is 800 Mhz

rf 52+ is 700 Mhz

rf 38+ is 600 Mhz

Lots of phones support these frequencies.

Kind of annoying for tv, because cell towers on frequencies that used to be tv frequencies can overload amplifiers, so peeps need to go put filters up before the preamp.


It's not a great UI, but for messing with ideas in a VM, the free tier is very hard to beat, otherwise I'd be on Claude Code, but still on a VM, because I won't let them near anything I actually care about.


Easiest to use when sshing into a VM.


I was inspired by that post also, got a Qwen Coder 1.5B up to 27tok/s prompt eval and 13tok/s decode on an e5-2650v2 inside a GNOME box


I've been watching and waiting for this, interested to see how smart it is, as it fits with my interest of getting the smartest possible model running in 10GB of VRAM (RTX3060 that has to drive 2 monitors and run an llm)


Toss the rtx into a cheapo optiplex or thinkcenter, and run it headless - the load on your machine is gonna make doing other stuff while it’s running painful. Plus that frees up the rest of your vram.


Running an llm on a PC running a desktop environment really isn't that bad. You lose a bit of ram & vram but that only matters if you _reaaaally_ want to push to the max model size your hardware can handle.

The biggest issue I've found is absent mindedly opening YouTube or the like that spike ram requirements and freezing the system up. But that's a me problem


Why would they do that when they already have a perfectly good PC?


…? I said why.

> the load on your machine is gonna make doing other stuff while it’s running painful

Is your question about something else?


I aspire to someday move up to an AM5 system, but for now, the Dell T3610 has to do everything. Might get a second GPU for it though.


start saving your money.


Or watch and wait as models get denser


I can see the appeal, not having to deal with much rust or bolts breaking (the 2 things which cause the most trouble for me in working on vehicles). 800 miles across the desert is some way to run it in though!


Opencode's free models have been fine for me, they're what I tried after Gemma 4 8B proved hard to persuade into usefulness (I want to revisit with 12B and messing with harnesses, but I'm happy for now).


Unfortunately there's no gguf quants of the assistant model yet: https://huggingface.co/models?other=base_model:quantized:goo...


I think MTP Gemma4 support is still WIP https://github.com/ggml-org/llama.cpp/pull/23398 ?


This has been my impression.

The underlying LiteRT-LM framework used in the edge gallery does support the MTP drafters for the smaller models, but according to:

https://developers.google.com/edge/litert-lm/models/gemma-4

> Note: LiteRT-LM supports E2B and E4B models today, with support for larger models coming soon.

So even Google aren't shipping MTP support for the 26B and 31B models yet.


Update: not any more!


That's what I want to know too. A smarter E4B that's happy in opencode would be a good selfhosted model for me


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: