kimburgess

I wouldn’t carry a voice only phone, or a text only messaging device, or a standalone GPS, music player, or PDA. But I do find a phone that combines these pretty useful.

Comment · 3 years ago

You can already do that with an iPad (sans fat OS). If you're using Blink Shell (https://blink.sh) the external display is independent of what's on the iPad too, which works really neatly. This is the exact setup I used as my main dev machine in a previous role.

Would be very nice to see if this works on the new iPhones. A thin client with decent security in your pocket with keyboard/mouse/display at both home and work seems like a very approachable computing setup.

Photo for reference: https://twitter.com/_______kim/status/1348736952330301440

Comment · 3 years ago

For those using the Apple Watch: would you recommend it?

I was an early(ish) adopter of smart watches/wearables - think Pebble and LG G Watch era. I walked away from that experience with the perception they exist solely as expensive distraction machines with an extremely short functional life and have been enjoying mechanical watches since.

This tech has me on the verge of trying again. It's seems to be getting pretty close a ubicomp device. There's enough compute onboard to do useful things with the sensors, particularly with the addition of the neural cores. The UWB proximity awareness look interesting too for someone with other apple devices (HomePods etc).

What I'm not familiar with is the current software ecosystem. Are there any core functions or third party apps that make use of this outside of just slinging notifications?

Comment · 3 years ago

Another advocate of this approach here. Define some form of time-boxing: 90 minutes, 3 hours, 1 day, 1 week, whatever. When this is up force a capture of current state, knowledge, assumptions and ideas, then walk away and intentionally drop context. When you return it’s a great spot to be self critical and reorientate towards what you’re actually trying to achieve. Think of it like async rubber-ducking.

If you continue to think about the problem space during that ‘off time’ (which you likely will) add the thought to some notes for review when you return.

Comment · 3 years ago

Absolutely - YCbCr 4:2:2 and 4:2:0 use different encodings across the lines to balance bandwidth. Complexity then continues to stack with deep colour pixel packing. There's a beautiful pocket of simplicity for RGB 4:4:4 8bpc which is essentially a direct digital encoding of ye oldy RGBHV signals. More than OK for any retro-comp needs, and a fun starting point for general hacking.

Comment · 3 years ago

That's only the case in the (relatively) shiny new 2.1 spec with FRL. Prior versions are TMDS with 3 channels for red, green, blue, along with a clock. The audio and InfraFrames slot into the data islands in blanking periods on those signals.

Comment · 3 years ago

That’s an amazingly beautiful build.

Comment · 3 years ago

For this style or abuse mitigation I’m always surprised that HashCash [1] or similar simple, locally implemented proof of work mechanisms aren’t more common.

This can be implemented in a way that remains transparent (albeit via JS), poses little impact on ‘good’ users, but protects against a lot of traffic patterns that may be undesirable. The cost can be scaled to match infra capability and the challenge can be a combo of the request data and time. Valid windows for that time can then be synced with cache validity which removes the need to keep tabs on any state.

For those deeper in this space. What am I missing here that prevents this from being the norm?

[1]: http://www.hashcash.org/

Comment · 3 years ago

Another host to consider with AU presence (both Sydney and Melbourne) is Vultr.

Not associated, but have been using them for some personal infrastructure lately - it's a really nice platform. If you have strong isolation requirements they have bare metal options too.