i am not sure i would trust a two month old project "based on a three month old proof of concept" over a product that has been around for years, but it is good to know it is there
What to trust? Closed hardware/software that goes to trash if something goes wrong, or opensource that you can send an agent to debug if there are issues? I'm not trying to diminish JetKVM's product - for $35 its a steal if you don't want to bother with DIY and time involved, but I'd strongly disagree that opensource is less trustworthy than closed product.
Also they say they are open sourcing the reference implementation of the "JetKVM OS Services" and the firmware of the "JetKVM Mini".
My point is more that it is way easier to make mistakes in source than it is to review said source in a project like this. So, to me, it is kind of risky to use something very green that is meant to be used as a network appliance more or less.
Maintainer (espkvm) here. :) Thanks for the mention ;)
It started as a firmware for myself: I wanted a KVM, but not a Linux system inside one. A colleague talked me into publishing it and it grew from there. It runs on ESP32-P4 dev boards, no custom hardware.
I am not saying it is better than JetKVM. What I find more interesting is that the Mini landed on the same chip. Their stack is completely different from the Linux JetKVM, so it must be a rewrite from scratch - a sign the idea of a KVM without an OS holds up.
Have you considered using usb-hdmi capture dongle instead of using hdmi-csi. That is my idea, you bring your own capture dongle, plug it in and good to go. The esp32-s3 (and P4 i guess) support usb host, and there is uvc example from esp-idf.
If you have same schedule every week, don't go on vacation, your kids don't have breaks, don't have seasons, then 'set and forget' dumb thermostat will work for you without any problems. For the rest of us we need some 'smartness' in our thermostats.
You shouldn't need to change the temperature regardless of those things. My house remains at 68-72F basically all the time. Thermal cycling accelerates aging of materials.
Do you have any citation for thermal cycling through the range of an AC inside a house affecting the failure rate of any household goods? Based on my experience this does not seem likely to be the case: thermal effects tend to be exponential or high powers of temperature, and most thermal cycling that people worry about is on the order of 100C or more. 10/20C of variation seems unlikely to be relevant.
(There is a case where if your house is well insulated enough, then it can be worth avoiding cycling your AC during the day, because it is both less efficient and will wear more while pulling the temperature down and this can be worse than just leaving it running in a sufficiently insulated house. It still is probably worth turning it off if you're away for a week, though)
> because it is both less efficient and will wear more while pulling the temperature down
That's just not true. Aircon is a heat pump. It pumps heat more efficiently when more heat is available to be pumped.
Warmer indoor air increases evaporator temperature. A higher evaporator temperature means that the system operates with less temperature lift. This means that the system does less work (per BTU pumped) to cool a house that is hot inside, than one that is already conditioned inside.
Equipment longevity also tends to be increased with less-frequent, longer runtimes than with more-frequent, shorter runtimes. There's less temperature cycling, fewer in-rush current events, and the lubricating oil in a running compressor is actively circulated to the parts that need lubricated. Reducing the number of compressor start-ups is a good thing; these machines like to run.
So even if same number of BTUs enter the home and need pumped out whether the aircon is running or not, then: Letting things warm up inside when there's nobody home to care about that constitutes an improvement in a broad number of ways.
Reality is even better: On a hot day, a house that is hot inside takes in fewer BTUs than one that is cool inside, due to the reduced temperature delta between indoors and out. When we have fewer BTUs coming in, then we have fewer BTUs that we must ultimately pay to pump back out.
But with most houses, the AC will cycle on and off throughout the day anyway - raising the temp while you're gone will often result in less cycling. Especially if you also increase the hysteresis range while out. So you get a triple efficiency win, from better AC efficiency, less AC motor wear, and less heat loss to the outside.
Isn't the thermal cycling greater outdoor than indoor because of the differences in the outdoor temperature between day and night? So most ordinary materials indoors should be fine with a delta of even 10 Kelvins/10 Celsius/18 F.
All of the material thermal failures I can think of come from localized and more extreme sources: electronics, lightbulbs, washing/drying clothes, washing dishes in a dishwasher. Water below freezing point too, but that's because the temperature fell below a threshold. None of these are from heating or cooling rooms directly with HVAC.
Yes, it's MUCH worse outdoors, but indoor temperature (and humidity) swings are not good either. I guess most people here just haven't paid enough attention to it as it's a very long-term effect, but definitely noticeable.
Everyone I know offline keeps their house at a constant temperature year-round, yet apparently it's controversial enough to be a downvoted opinion here? WTF?
As in scientifically proven to be biologically ideal, proven to have the best sleep outcomes. You can have different preferences of course, doesn’t change what’s ideal.
On many models that I tested in past context quantization had very bad effect on model performance. However qwen3.8 27b is different.
I'm now running NVFP4 quantized both weight and cache on my RTX5090 and getting excellent results: 264k cache allocated for pool, 10k tok/s prompt processing, 200 tok/s generation for single stream, or 801 tok/s generation for 8 concurrent streams.
Also have about 2Gb vram left for use of OS.
my coding agents regularly reach 200k context used without noticeable degradation.
I’m running 27B on a 5090 as well, and the results have been really strong. It does almost as well as, and sometimes better than, a 121gb DS4 model running on an M5 Max 128gb. 27B also flies on the 5090, and at medium think it returns results many times faster than my DS4 setup (the default xhigh is basically broken, though).
For the kinds of things I use a local model for (legal document review), it’s just spectacular. It also has good vision support. I’ve been using 27B more and more over DS4.
it is, unless it set to xhigh - it really likes generating tons of tokens for its thinking. unfortunately, for decently reliable coding results you want it on xhigh ...
why so many people add 'please' when asking machine to do something? Was there actually research that when you SCREAM or curse it follows your instructions better?
P.S. Although my wife insists that I should stay polite in case AI overlords remember how I treat them ...
I'm polite to LLMs. It's not for the models it's for myself. If I start being rude to models then I might accidentally start being rude to other people as well.
Probably because polite people are already in the habit of saying please when typing out requests in chat. We're not consciously thinking about it, regardless of whether a human or machine is on the other side.
Not to go all ying/yang about it, but just to give a parallel: https://en.wikipedia.org/wiki/Loudness_war - you kinda need silence to draw a contrast with what's meant to be loud.
Separately, my boss confided in us that he's super abusive with his agent, wondering if we are too (no, lol). While I try not to read too much into this (which he doesn't make easy), I also can't help but not really notice a whole lot of amazing agentic delivery differences from his side. On the contrary, while the passion may improve his agent's performance, I'm not sure if it doesn't decrease his, upending the entire theatre.
I think about removing please/thanks, but then I accidentally add them back in during some edit/rewrite of the prompt... It's just how I'm used to asking for things
Interesting - in my setup (llama.cpp rtx5090 qwen-3.6 27b) prompt processing with mtp is almost half vs non mtp. Sounds like I need to investigate what is wrong.
Maybe enabling MTP causes some weights to be displaced to host memory? MTP itself doesn't do anything during prefill so that should be exactly unchanged, decode will vary depending on settings but with 2-4 proposals depending on workload I've never seen an overall slowdown.
edit: I recommend building recent llama.cpp from source, I've been updating about once a week, as there has been a fair amount of work related to MTP recently. If you're running a lot of tool calling on Qwen you might also benefit from one of the bugfixed chat templates like the Froggeric version.
There was lots of discussion within Russian and Ukrainian war analytics that nukes (at least tactical) are useless in this war for the following reasons:
- they would not change much on battlefield - there is no large concentrations that you can nuke - everything is dispersed
- nuking urban centers again won't change much on battlefield but would alienate China
- Russia's equipment is known to be not most reliable/maintained and worst that can happen to Russia is them trying to nuke and nukes not working
Nuking all the major population centers would pretty much destroy the ability of Ukraine to manufacture weapons in any meaningful number and it would also deprive its army of any new soldiers, no reinforcements, no food supplies and so on. I think it will change the course of the war pretty fast and pretty drastically.
You're mistaken. A significant portion of Ukraine's manufacturing now happens abroad, out of Russia's reach. Meanwhile, a large part of its domestic production is decentralized and widely distributed. (You can easily find snobbish and pejorative comments by Rheinmetall's CEO about this.)
Nuclear weapon use would lead to no meaningful military success, but it would immediately alienate the superpower Russia depends on in almost every way. China will not tolerate any nation using nuclear weapons. With its extremely dense population, it can't afford a modern wartime precedent to be set for their use.
I'd say adding another 16Gb gpu would be worth it - you'd be able to run larger model/larger context all within gpu's. It would give you more options of what you can run fast. Your current model probably doesn't run completely from GPU (depending on quants I don't think you can squeeze Gemma4:26b into 16Gb vram), so you already have some layers running on gpu and some on cpu. If you add another gpu you might be able to move all layers to vram which should speed up things for you. The layers calculations happen on whatever gpu's it sits, so the layers that are already on your rtx5080 would compute same, but the layers that currently your cpu handles will be computed with faster vram/compute of rtx5060.
Thanks! I'm seeing a 10/90 split between CPU/GPU with gemma4:26b, so I guess there's at least something to win there by adding the other GPU. And perhaps something to win by connecting the monitor to the iGPU instead to free up VRAM, from what I gather.
Just in case someone should be interested in how a consumer PC setup like this performs, still using only 1x RTX 5080 + 64GB system RAM and Intel Ultra 270K-Plus; I tested Qwen3.6:35b-a3b now (using ollama and default settings) and I'm getting around ~86 t/s. The lowest I've seen so far is 70 t/s. The CPU/GPU split with 35b is 39/61% (with 4K 165 fps monitor connected to 5080, so there's probably some room for optimization here by moving it to the iGPU).
Best thing is that this setup is basically dead silent (it could, hypothetically speaking, be running in my bedroom just fine, and I'm a light sleeper).
> The Department of Defense said the xAI data center powered by the gas plant is critical to national security, revealing Grok was used to fire thousands of missiles in the Iran war.
reply