I did lots of interview on both sides and know how often interviews are just luck - got asked trick question that I knew answer to, coding problem that involves algorithm I just recently used, etc.
There is so much randomness that I, as interviewer, decided on the following strategy - put candidate into best possible position and judge from that. I settle on one set of questions - "tell me about your most favorite project, why, and let's discuss in detail". If candidate knows his/her stuff - this is fun/informative discussion. Also easy filter if a candidate cannot say much or doesn't understand details of project they consider their favorite.
I did many "interviews" as a casting agent for films, so finding the suitable actors for one or more roles in limited time.
Thank you for highlighting the randomness, because I can't understand the (what must be fake) confidence of some interviewers in their assessments. They think someone who aced the interview will be good in their role at work. How often I had to work with what can only be described as sly, but lazy con-men that "really interviewed well", but couldn't even do the most basic tasks, says otherwise. Unless their role is doing interviews all you get from an interview requires some degree of extrapolation towards the real job. Additionally people may have different days, different characters that make them shine or suck at doing interviews and maybe that specific task was just a mismatch and another one would have made them shine.
Interviewers that are not aware of this have not reflected what it means to do their own job in my opinion.
This is why I also try to make the interviewees shine by giving them the best cards possible. To some degree that mitigates the randomness and it also helps soothe overly anxious or excited candidates. They should get the feeling that I as the interviewer try to solve the posed problems together with them, not that I throw bricks their way and try to misunderstand everything they say. I also try to make the tasks in the interview emulate what needs to be done in the actual job/role. Everything else would be silly.
I have actually gotten great feedback on that way of doing interviews over the years.
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 is so much randomness that I, as interviewer, decided on the following strategy - put candidate into best possible position and judge from that. I settle on one set of questions - "tell me about your most favorite project, why, and let's discuss in detail". If candidate knows his/her stuff - this is fun/informative discussion. Also easy filter if a candidate cannot say much or doesn't understand details of project they consider their favorite.
reply