One of the white Macbooks used 50 screws to fasten the keyboard. Once I spilled some juice on it and had to replace it.
Took forever, but at least back then it was not too expensive or difficult.
Could have been worse: I replaced a keyboard for a friends daughter and her Dell had ~50 plastic studs holding the keyboard in place, each one was melted rivet-style. I had to remove enough that I could get the keyboard out, but not so much that there wasn't still plastic to melt to hold the new keyboard in place.
If I remember right, a problem with this is that you need to get those proofs by submitting your id or similar, you only get a limited amount of proofs at a time, they expire in maybe a few months, and you can only get them using a government specific app that is only for "secure" devices. Instead of being tracked by the site you're being tracked by the government, you now need a Google Android phone in order to browse adult sites on your PC, and depending on your habits you may need to re-show your id potentially multiple times a day unless you opt to being tracked by the sites instead.
It really should be just once that you need to show your id and then you should be able to generate as many proofs as you need whenever you need on any computer device, but they have an obsession on making very sure that it cannot be circumvented, as if it was insanely important.
Part of the definition of vibe coding is not looking at the code. If you read code you are not "vibing" anymore, you are just using AI tools to write code.
“using AI tools to write code” is too clunky of a phrase. Unless someone proposes a sticky two/three-syllable verb (that people actually want to use, inb4 some sarcastic person suggests “poop-coding” or something) then people are going to fall back on vibe-coding because it’s quick to say, its definition will become blurred, and we’ll have no one to blame but ourselves.
Given an arbitrary causality graph between n messages, it would be ideal if you could consume your messages in topological order. And that you could do so in O(n log n).
No queuing system in the world does arbitrary causality graphs without O(n^2) costs. I dream of the day where this changes.
And because of this, we’ve adapted our message causality topologies to cope with the consuming mechanisms of Kafka et al
To make this less abstract, imagine you have two bank accounts, each with a stream. MoneyOut in Bob’s account should come BEFORE MoneyIn when he transfers to Alice’s account, despite each bank account having different partition keys.
Can you elaborate on how you have “adapted…message causality topologies to cope with consuming mechanisms” in relation to the example of a bank account? The causality topology being what here, couldn’t one day MoneyIn should come before else there can be now true MoneyOut?
You give up on the guarantees across partition keys (bank accounts), and you accept that balances will not reflect a causally consistent state of the past.
E.g., Bob deposits 100, Bob sends 50 to Alice.
Balances:
Bob 0 Alice 50 # the source system was never in this state
Bob 100 Alice 50 # the source system was never in this state
Bob 50 Alice 50 # eventually consistent final state
Example Option 2
You give up on parallelism, and consume in total order (i.e., one single partition / unit of parallelism - e.g., in Kafka set a partitioner that always hashes to the same value).
Example Option 3
In the consumer you "wait" whenever you get a message that violates causal order.
E.g.,
Bob deposits 100
Bob sends 50 to Alice (Bob-MoneyOut 50 -> Alice-MoneyIn 50).
If we attempt to consume Alice-MoneyIn before Bob-MoneyOut, we exponentially back off from the partition containing Alice-MoneyIn.
(Option 3 is terrible because of O(n^2) processing times in the worst case and the possibility for deadlocks (two partitions are waiting for one another))
Thanks. With these of examples of messages appearance in time and in physical location in Kafka, how have you adapted your consumers? Which scenario / architectural decision (one of the examples?) have you moved forward with and creating support to yield your desired causality handling?
Option 1, but after so many years banging our heads against the wall reasoning about this, we hoped someone would eventually give us a queue that supports arbitrary causal dependency graphs.
We thought about building it ourselves, because we know the data structures, high level algorithms, and disk optimizations required. BUT we pivoted our company, so we've postponed this for the foreseeable future. After all, theory is relatively easy, but a true production grade implementation takes years.
hmmm... could this be solved by "vector clocks"? if producers are emitting something that depends on a previous event they send the id of the previous event. (so like capabilities, you need proof of "data access".)
or the problem is that again this is O(n^2)? (because then the consumers now need to buffer [potentially] n key streams (and then search for them every time - so "n" times)?
Very cool! I thought maybe I'll take a crack at building a better iOS application for these things, but then I remembered that for the Lightning connector you needed to get the permission of the manufacturer if you wanted to interface with a device (tried that once with a Lightning Yubikey and luckily they didn't have any objections).
Is this not an issue anymore with USBC iPhones?
USB-C iPhones work with all kinds of USB-C hubs, devices, keyboards, mice, Ethernet adapters, etc out of the box.
As far as I have seen, USB-C on iOS devices has no authentication restrictions for anything.
The device in the article already has an iOS app, so while there may be a needed app entitlement, I don't think there are any showstoppers for making an iOS app for this particular thermal camera.
I would love to be wrong, but I can't find anything that suggests USB webcams work on USB-C iPhones - I did try in the past for different reasons but couldn't find any way of making it work.
What surprised me is that iPadOS does have uvc functionality, but iOS doesn't. If you have an ipad with a USBC connector, can try it and will work. For example I used the Orion app for ipad and it will show me live feed of any connected uvc camera.
I built an interposer board to do this about 5 years ago (for a product that didn't go anywhere). Ended up using a beagle bone in USB gadget mode to expose an Ethernet adapter to the iPad I was using.
I would switch over to Zed for all my non-JVM needs if only it would have a debugger support. Currently it's filling a role of a text editor pretty well though.
