962 karma · joined September 28, 2016
* https://ianhowson.com -- my blog
* https://rdrr.io -- the world's most comprehensive index of R package documentation
Feel free to email me anytime -- ian@mutexlabs.com
It's still a great design.
Also every person that walks by your desk will interrupt you to say "that's a weird keyboard."
I found enough reports on Reddit that I figured it was worth trying, and I used a Kinesis Advantage for a long time.
If you haven't used a Kinesis, I would recommend buying or borrowing one first. The price of a KA vs. a from-scratch Dactyl [Manuform] is similar, but the KA doesn't need assembly and is easy to resell if you don't like it.
At this point I have a ton of keyboard parts lying around, I've used QMK a lot, and I have strong preferences for certain switches (which I already own), so the cost is just the 3D prints and assembly time (also low, because I've built a few keyboards from scratch before.)
And this is where I don't know what to think because "keep it all in vRAM" is clearly a terrible algorithm, and I have faith in the macOS developers, and yet my data suggests that this is exactly what they're doing. I don't see things swap out when there's memory pressure; it just keeps on allocating until it's full, then spills over to system memory and makes everything slow.
Counterintuitively, the iGPUs have an advantage here. They always run from system memory but they have a faster path to system memory -- they don't need to operate over PCIe -- so (a) you don't have a large perf gap between the 'full' and 'not full' cases, and (b) spillover doesn't hurt. You use a lot more RAM, but you can buy more of that. I can't easily add RAM to my GPU. At best I can double it, and that just means 70 Chrome tabs instead of 35.
I'd love to hear from someone at Apple who's seen the internals of this.
1. MacBook 12" 2015 feels dramatically faster at 1x scaling vs. 2x, even with the same output resolution (2560x1440@1x vs. 1280x720@2x.)
2. Mac with 8GB RX 580 GPU. With >1x scaling, as I add load (i.e. Chrome tabs) it eventually runs out of GPU memory and starts paging to system RAM. The whole thing grinds to a halt at that point.
The rendered pixel count makes this effect worse -- dual 4ks are slower than a 5k, is slower than a single 4k, is slower than dual HDs. This is to be expected, but we're talking about an 8 gigabyte GPU, and the framebuffer sizes should be a tiny drop in the bucket.
None of this happens at 1x scaling. Running a native (2x) scale factor feels a little faster than a downscaled (2x -> 1.5x) scale factor.
As far as I can tell, load and GPU mem usage scales with:
(number of GPU applications * total rendered pixels) ^ k.
At 1x scaling, k is close to 1. At HiDPI, it's greater than 1.
And the only reason I want that RAM is for Chrome.
Then they started false triggering about every ten minutes. "Hey Siri, decrease sensitivity" does nothing. "Hey Siri, set a timer": "nope your $4k computer can't count time."
Turned it off. Sorry.
Downsides are (a) butterfly keyboard and (b) tiny screen. If you do anything that requires compilation, get something with a CPU fan like the new 13" Air.
Get the 16GB model either way.
I just want to take my data from here... and put it there... and not have it trashed along the way. I will pay money for this service.
I would be happy to pay money to make this work properly.
In the meantime, I pay extra for Google Photos (for display/search/tagging) and iCloud (for reliable auto backup) and need to find a way to automatically download the iCloud things to my Plex/NAS machine.
ARM and x86 are both capable of very high performance. ARM isn't magically capable of putting out 10x the FLOPS in the same power envelope. Modern x86 parts are very close to ARM in terms of work completed per unit energy consumed.
The difference is that it's rare to see an ARM part with a heatsink/fan and it's rare to see an x86 part without one. RPi and MacBook 12 are notable exceptions to this.
All of this presumes that CPU utilization is what's eating the power. It's not. For an idle machine (e.g. ARM iPad vs. x86 MacBook) most of the energy goes into the display backlight. The SoCs idle down to near zero energy consumption.
It's even difficult to assert that CPU usage is a big power culprit on these machines. My MacBook 12 can max out CPU forever and hold 1.8GHz with no fan. The 4 core post-Haswell MacBooks can max out their CPUs and have the fan running very slowly. But run the GPU hard on either of those machines? You'll max out the fans and power consumption immediately and things will start throttling.
TL;DR: CPU arch makes no difference. ARM Macs will have similar cooling solutions to the current ones.
It's noisy, though.
I'm comfortable designing and assembling PCBs but don't really have time to debug a brand-new design, so I've ordered a low-profile Lily58 kit. The Lily58 is most of what I want and has open source PCB, schematic and case. If it doesn't work for me, I'm expecting to modify it to something more like Quefrency.
There's a ton of 'decade behind' stuff that runs in VMs on Win10 machines.
22kHz sampling isn't a problem in practice as:
- HAs focus on speech comprehension, not music. Speech doesn't high much content above 5kHz, so even 22kHz is double the Nyquist rate.
- Music is perfectly enjoyable at 22kHz (but obviously better at 44kHz)
- People getting hearing aids have hearing loss, and the majority of hearing loss is in the high frequencies
- Digital hearing aids are smaller, lower power and easier to configure than analog hearing aids (think "fits in your ear canal" vs. "you wear the original iPod on your belt")
- The benefits of full-analog audio are contentious at best and almost certainly imperceptible for people with hearing loss
If you want further convincing that A->D->A conversion is perfectly fine, https://xiph.org/video/vid1.shtml is excellent.
My last project couldn't use a giant cap because of size, not cost constraints.
Assuming you only need to execute one Flash transaction (doubtful!), covering all of the variation might take upwards of 50ms.
So, yeah, you could just throw a massive cap on the power rail. Except that that conflicts with the other power, cost and size constraints implicit in the context of microcontroller systems.
(a) you don't choose how long you get because the uC manufacturer already chose. (An external brownout warning is different, and useful, but still not a good solution to the problem of FS integrity.)
(b) those thresholds have nothing to do with the operating thresholds of the flash (which usually require a lot more energy to do work than the uC)
(c) writing to flash is a relatively high-power operation, and if you need to erase, you're doing the highest-power operation at a time when you have no power buffer
(d) warmup time to do an erase is measured in milliseconds, and you probably don't have that much power buffer
The best you can do at brownout is minimize the damage, because your uC is about to switch off and/or silently inject errors.
(I never figured out, despite 'ergonomics training', how I was supposed to hold my extended hands and arms upright for hours per day without shoulder and neck pain.)
This isn't about 'garbage software'; it's about the expectation that a local LAN is not exposed to the Internet and therefore does not need the same security controls that an Internet-facing network does.
Browsers making requests on the LAN breaks this expectation.
Before someone says "but I don't expect that", well, why do you even have a firewall? With the notable exception of Google/BeyondCorp, practically every LAN in the world expects to trust its members. Having untrusted code in browsers able to send requests on the LAN violates that expectation.
Similarly, there are legitimate reasons why I might want to access a service with an invalid SSL cert. They're rare and should be discouraged for general users.