well, i agree that your chat message being delayed for 5 seconds is not critical
but waiting 5 seconds for a keystroke to be echoed (sometimes) is appalling. you would not get permission to do a user study from an irb. it would be denied on grounds of needless cruelty to experimental subjects
it would fit the use case perfectly if you had a low-power microcontroller that updated the screen in response to keystrokes, but what you're describing is a user interface design botched for no good reason
even the rp2040 would work for that at the weekend level
this is not quite a 'solar freakin' roadways' level of mistake because you could fix it with relatively minor tweaks to the design, but if you don't, you'll be left with a design that's unusable on battery, either because of battery life or responsiveness
fwiw i don't think restarting a computer in response to a keystroke is an elaborate workaround at all; that part of the design is perfectly reasonable
check out how mosh predicts keystroke effects for 'speculative local echo' and think about how you could do that on the rp2040 (or ideally an esp32 or apollo3 or something) while you're waiting on the giant linux behemoth to awaken from its slumber and restart gomuks or vim or whatever
that's the plan i think will give you three hours of battery life: 2 amp hours times 3.7 volts divided by 2.5 watts gives 3 hours of use. 36 5-minute timeouts. do you have a different estimate? did i miscalculate?
that's not a weekend
in that comment i also explained an approach that would beat that by two orders of magnitude if you applied it with the same components (though there i supposed the hardware would use an esp32)
if it doesn’t meet your needs, then don’t buy the device.
You use “customers” as if this were trying to be a full product. This is a weekend hack. Of course there’s going to be low-hanging fruit that could be optimized away.
Stop shitting on the guy’s earnest enjoyment. What you’re doing is akin to going to your favorite package’s issues tracker and making a P0 request like “rewrite it in rust, python sucks”
you seem to have skimmed the previous messages and misunderstood them
it's not a weekend hack, it's a commercial product, designed and built by a team of several people. the weekend hackers (or chatters) are the intended customers; they are not the makers. they have 50 prototype units in stock, and they're taking preorders for two more larger batches which they expect to ship in august and september. august is 70 days away, an interval which is 35 times larger than a weekend
the 'weekend' aspect is how long the user should expect it to work for, not how long they've spent on developing it
unfortunately, their current design seems to have a fatal flaw that renders it useless for its intended purpose, but one that's easily fixed
my comments are not shitting on it; they explain how to fix it, providing information the original designers were evidently unaware of, so that they can ship a product that fulfills its intended purpose, which would probably make them a few tens of thousands of dollars. up to them if they want to do it or not; i'm not an investor. if they don't, probably someone else will
i could of course be mistaken about this, but so far there's no reason to suspect that i am; the pushback in comments here has all been ego-driven posturing like 'This power management scheme fits the use case perfectly.' instead of something like 'actually i have a rp2040 deep-sleeping at 100 microwatts' or 'i have this pi zero w running at 700 milliwatts with such-and-such a kernel config so actually they'll get 12 hours of battery life'
but waiting 5 seconds for a keystroke to be echoed (sometimes) is appalling. you would not get permission to do a user study from an irb. it would be denied on grounds of needless cruelty to experimental subjects
it would fit the use case perfectly if you had a low-power microcontroller that updated the screen in response to keystrokes, but what you're describing is a user interface design botched for no good reason
even the rp2040 would work for that at the weekend level
this is not quite a 'solar freakin' roadways' level of mistake because you could fix it with relatively minor tweaks to the design, but if you don't, you'll be left with a design that's unusable on battery, either because of battery life or responsiveness
fwiw i don't think restarting a computer in response to a keystroke is an elaborate workaround at all; that part of the design is perfectly reasonable
check out how mosh predicts keystroke effects for 'speculative local echo' and think about how you could do that on the rp2040 (or ideally an esp32 or apollo3 or something) while you're waiting on the giant linux behemoth to awaken from its slumber and restart gomuks or vim or whatever