Sorry, but as someone who's owned a v1, the first 12" Pro, a Mini, and now an M4 Pro: hahahaha, no.
Durable, yes. Given how many hours each of my iPads has spend in my kids' hands I can't really complain on that front.
But repairable? Not in any meaningful way. When the battery gets too weak you can use it as a tethered control panel for media or smart home apps; when the screen cracks you can slap a protector on it. Aside from that, any hardware fault outside of warranty means it's DOA.
The most common use-case for the rear iPad camera in our household is stop-motion animation. There are some great apps for this, and the big screen (when effectively stabilized on a tablet stand or tripod + clamp) is lovely for composing and comparing frames.
But UUIDv7 has one key advantage none of those do: you can store them in a UUID-typed column or struct field without any lossy conversion. All of the UUID versions share a common size and serialization format, so it doesn't actually matter if you generate v1/4/7/etc.
Many language standard libraries can generate them interchangeably, and (for example) a Postgres table can store any of the versions in the same column type.
So yes, to the author's point(s): they are not magic, monotonic, un-guessable IDs and you shouldn't treat them as either "secure" or strictly ordered. That doesn't mean they aren't useful.
ULID is what I use. I convert it to UUID before storing in PostgreSQL. Technically it's an invalid serialization but it works. The system predates UUIDv7. I also like ULID's shorter representation.
I did that with SQL Server for a time. It was particularly a strange serialization because I tried to match ULID ordering with SQL Server's UUID sort algorithm.
I think the core problem isn't that the Noise "API" is confusing, it's that Noise is a framework for building reasonably-secure protocols. If you don't know how to build or evaluate cryptosystems, you shouldn't assume that just dropping in a library will somehow make your novel network protocol secure.
"Don't roll your own crypto" gets a lot of lip service (and a fair number of eye rolls) but it's really, truly something worth considering because it isn't just the algorithms or libraries you choose: it's about the whole package, including things like wire serialization, internal handshakes/security, etc. Just grabbing a Noise tutorial and building your own implementation is a Bad. Idea.
And this is only getting worse now that people can prompt their way through building a "secure" system only to realize they really didn't understand what that means. No amount of Markdown saying, "don't introduce a cryptographic vulnerability in this code" is going to save you if you don't know what to do in the first place.
But also: the vulnerability was literally visible using basic Wireshark/pcap traffic sniffing. I'm sorry, but if you don't even bother (or know how) to do that kind of basic security analysis you should stop and look for someone who does to check your system in the real world before you tell people to depend on it for serious work.
(That being said, if someone had just typed 'find me a vulnerability in this protocol' in a code agent backed by Fable or Astra with any kind of access to network traffic dumps it probably would have taken about 15 minutes to discover this issue. Might even be significant part of how the above author found it, given the other LLM-ish fingerprints in the writeup.)
Depends on your networking setup. A good switch will simply refuse to route packets between clients on different VLANs, and hide the existence of the tags that determine which VLAN a host is on.
A bad switch or router (which almost certainly includes a ton of crappy home APs and routers, compromised by the same actors who ship these devices) could let clients see VLAN tags and ignore them.
Also: if you need a streaming box to see your AirPlay or UPnP devices for “casting” it necessarily has to be on the same VLAN as the devices it’s connecting to. Sonos speakers have this problem when subject to client isolation setups based on VLANs or switch-level packet filters.
And any kind of multicast (used for local service discovery and media streaming) has the same limitations.
I wouldn't minimize the potential contribution of the teams building + evaluating the models, either.
If you have an entire office full of "lib-left" hackers, executives, et. al., their biases are going to have an effect on the models they build, irrespective of source material.
As an example: there's a lot of well-established science in support of anthropocentric climate change. And yet, interpretations (or even acceptance) of that science have become political dogma.
I think it's probably safe to say that engineers broadly trust science, whatever their personal views on social or economic policy. So models that are trained and evaluated on following scientific consensus will easily be tagged as "left-leaning."
The "dock" comment made sense to me because I don't think that true "road warrior" laptop use and 10G Ethernet deployments would coincide all that often.
I've put a disproportionate number of hours and $$$ into my homelab over the years, and I still only have 2.5G Ethernet switches deployed. Most offices' (much less home/coworking space/etc.) network traffic is passing through single-gigabit switches.
This is where my head is on docks. When your connected to enhanced infrastructure (like your home lab) sure, but when you're checked into the Embassy Suites? Not particularly useful :-).
That said, I'm kind of sad that Framework and others have generally opted to let "third party USB-C docks" be the docking solution. I miss the days when my Thinkpad dropped onto its docking station with a purpose build bottom connector and seamlessly became a desktop/deskside type computer that was wired into my desk setup. Sadly I think that vision of docking died with the Thinkpad's sale to Lenovo.
I have a 5gbps symmetrical fiber connection at home, so I've spent a fair amount of time and money upgrading my homelab backbone to 10gbps. That includes a 10GBe connection to my desk, but I've had issues getting the connection to be reliable (terminating the shielded Cat6A I have in the walls is a pain). That drop hasn't been working for the past few months, so I've been on wifi instead; it hasn't been enough of an issue for me to invest the time in fixing it.
The perspective from over here in HN land is very skewed.
According to the US Census, median household income in 2024 was $80,000. Add federal and state income tax* of 30%, and you're left with $56,000. Rent in lower-cost areas is around $12,000 ($1k/mo.) and health insurance (assuming ACA, not fancy private plans) is another $7000. Utility prices vary wildly but average something like $450-500 (so $6000 per year). if you don't live in a particularly high-cost area and skip luxuries like home Internet service or media subscriptions.
That's just over $30,000 left over per year for all household expenses, including "luxuries" like food, clothes, and car and home maintenance. Heaven forbid you have loans (car, student, etc.) or any revolving credit debt.
The difference between $5k and $10k in fuel costs is therefore easily 15% vs. 35% of total "inessential" spending. With food and other goods consistently been driven up by inflation and tariffs, there's just no margin for an "average" family.
(Sources vary for the above; US Census comes data from its own website, rent from TIME, health costs from Forbes, and utilities from move.org. Feel free to find better reference numbers if you doubt the above.)
*- yes, not all states charge income tax; most of the ones that don't have other taxes (sales, gas, property) to make up the gap
In California, yes; median income is around $100k. And of course, if you have kids, a mortgage, etc., you can qualify for plenty of tax incentives. OTOH, if you have kids your food, clothing, and transportation budget are almost certainly higher, and your ability to (say) relocate to find better wages are even more limited.
I stand by the core point: the median household income leaves very little room for major spikes in essential costs like fuel, housing, and health care. Any single cost jumping from $5k -> $10k is potentially ruinous.
That's a DoS attack, not "jamming". RF jamming usually relies on flooding frequencies with garbage which doesn't get interpreted as valid protocol traffic but does "crowd out" legitimate use.
The protocol-aware class of attack you describe does require some knowledge of the radio parameters being used, since LoRa runs on very narrow bands and uses both time and frequency-hopping to avoid congestion on any one virtual channel. They even apply (very basic) encryption to messages to prevent unknown senders from flooding the channel.
Unfortunately, both systems come preconfigured out of the box to use a default configuration which most users never override. So like cheap FRS/GMRS walkie talkies, all it takes is a few jerks who don't care about common use to overwhelm everyone with bogus messages. If you fire up a new device running the default Meshtastic firmware in any kind of dense urban environment, odds are it will more or less immediately get inundated with spam: "ping", "test", "hello from <neighborhood>", etc.
And since MT + MC both flood the shared channels to push messages across intermediary nodes, they pretty much self-DDoS by doing...nothing.
Durable, yes. Given how many hours each of my iPads has spend in my kids' hands I can't really complain on that front.
But repairable? Not in any meaningful way. When the battery gets too weak you can use it as a tethered control panel for media or smart home apps; when the screen cracks you can slap a protector on it. Aside from that, any hardware fault outside of warranty means it's DOA.
reply