This was stated about the key: "Folded into the base is a mechanical backup key, a flat metal blade in a hinged housing."
I own a BYD: this is not true. The key is not hinged; rather, the entire mechanical key pulls out when a small clip is unlatched near the top of the assembly (you can see it in the CT). I assume the circular hinge-looking mechanism in the CT is just a by product of the plastic/metal weld process.
I wasn’t surprised by the backup key, but rather by how empty it was. I really wish key fobs were smaller. They are quite bulky in a pocket and bigger than all my actual keys combined.
Now that’s an idea… I found one for my car, but kind of hate it.
I don’t have a 3D printer currently. I did help my cousin’s kid by one and they told me if I ever wanted to print something to let them know, but I have a feeling I’ll need to design my own with some trial and error.
I’ve hesitated buying one, because the idea of having a machine to melt plastic in my house seems like a bad idea when it comes to air quality.
Depends on the plastic, but even the most benign ones put out very minor amounts of fumes if YouTube testers are to be believed. Note that fumes in this case just means that they are seeing changes in AQI meters, which is something that can happen with too many people sitting in a room.
If it’s something you worry about, the enclosed models frequently either come with, or can be fitted with a carbon filter, and if you are really worried, you can use dryer vent to get it outside.
With the most popular plastic (PLA) at printing temperatures, there isn’t any data showing toxic byproducts. When you get into things like ABS and resin you have to think more about fumes.
Do not print a key fob out of PLA. It will not survive summer car temperatures. A better choice is PETG, or ABS and ASA if you have an enclosed printer that can vent outside.
I'm guessing parent-poster is saying the "is" should be "are", on the basis that the word "components" is plural.
That said, I didn't perceive a problem either, and my self-diagnosis is that "none of the X" feels like it could be evoking a singular item that failed to be found.
Yep, I think the singular is ok, as it could be just one. Seems like it could be both.
Cambridge says...
> In formal styles, we use none of with a singular verb when it is the subject. However, in informal speaking, people often use plural verbs...
Collins says:
> Since none has the meanings “not one” and “not any,” some insist that it always be treated as a singular and be followed by a singular verb: The rescue party searched for survivors, but none was found. However, none has been used with both singular and plural verbs since the 9th century. When the sense is “not any persons or things” (as in the example above), the plural is more common: … none were found. Only when none is clearly intended to mean “not one” or “not any” is it followed by a singular verb: Of all my articles, none has received more acclaim than my latest one.
But it was "none of -these- X" which (to me, at least) is a secondary signal for plurality indicating that "are" is (doubly) preferable to "is".
(I don't find "none of these components is ..." to be egregiously wrong but it definitely gives a brain hiccup where the "... are ..." variant is much smoother.)
I guess my intent was not to point out that it has a mechanical key, rather that the description of the key on the webpage was wrong (it is not hinged).
The mechanical key fallback pattern is standard across the industry for sure.
Article says key fobs are the same across all their cars and this looks the same as mine for a Sealion 5, there is no hinge for the key you just pull it out.
Likely the article authors just assumed from looking at the scan, if they’d actually tried to remove the key they would have realised their mistake.
Before keyless became defacto standard, most keys were fixed on a hinge - you'd first unlock your car by pressing a button on the fob, then swing the key open and use it to start the car.
Nowadays the physical key is only a backup, safely stowed inside the fob. It is meant to be pulled out only in an emergency.
Mercedes changed to the IR key in maybe turn of the 90's. The plastic blob would be used to turn the ignition like before, but the locking part was electrical (optical). There was still a metal key that could be pulled out and used on the exterior locks if the central locking was out.
When keyless start came, there was a dummy button that fit in the ignition lock that could be pushed to start. If there was a problem, you could pop it out and use the key as before.
IIRC, all that, so may have mistakes. Just crossed my mind that they went a few decades between no metal ignition key and keyless. MB being MB, I wouldn't be surprised if they still had models with that same "old" system and keyless as an option.
Yes sadly the Hyundai and Kia key fobs of EVs (at least EV9) don’t have the mechanical backup key in the fob anymore. So you need to carry it on your keychain. Don’t leave it in your trunk. If the 12V battery does out you won’t be able to get into the car.
Anecdotally on my Hyundai ionic hybrid from 2018 it does have a mechanical key in the fob, but it is very non-obvious. It’s physically the same piece as the keyring section at the top of the fob. There is a small catch you release to remove the key from the plastic fob body and it slides out the top.
All this to say Hyundai certainly knows how to do this. If they didn’t do it, it is almost certainly a deliberate omission.
I think the staunch "no screen" mentality is a broad-stroke lever that non-technical thought leaders in the child wellness space have stuck to, and I understand where they come from.
Though, as someone who owes his livelihood to being able to tinker and experiment with technology as a child, I'm looking toward a more measured approach. I may very well set up an airgapped Linux box (Windows has come a long way since the XP days, and gone entirely the wrong way) and let my kids proverbially "have at it" - this way, they can't get stuck in big tech's psycho-loops or sucked into YouTube's colourful dopamine machine - which I think, is the entire drive behind "no screens".
We set up a “kid laptop” for our kids (ages 3, 6 and 9) that has a short list of allowed websites and a curated set of installed programs.
We treat it like any other toy: they can pretty much play with it whenever they want for as long as they want. Of course they have to share it between the three of them, so there’s a natural limit there.
Every so often we’ll add something new; most recently I installed SimAnt after we were watching ants in our backyard.
I've never understood how this can be limited in practice: surely as far as the carrier is concerned, all traffic from the mobile device is the same (unless there are identifiers on the traffic coming from hotspotted devices via the mobile device). Here in Australia we've never had any form of hotspot detection/segmentation - if you have a data plan, all data features work (across all carriers). I do recall lots of online chatter from the US though, especially years back when mobile data was more of a precious resource.
Specifically it decrements the TTL of routed packets, so hotspot traffic will tend to have a TTL of 63 instead of 64. You could theoretically disable this at the risk of creating infinite routing loops, although android probably makes it inaccessible if the kernel has a setting for it at all, so you might have to rewrite packets in user space.
It has been a long time since I've done this, but:
If your Android is rooted, it's pretty easy to get tethering working. There's magisk modules that can fix the TTL problem and/or disable the hidden carrier-installed software that Android will ask for permission before enabling tethering.
Different applications on a single device can't apply different TTL's? I thought TTL was a pretty basic knob exposed to applications. e.g. A sensor that transmits fresh data every 20 seconds doesn't need stale packets bounding around clogging up the pipes, while a file transfer over an intermittently delayed link might benefit from a higher TTL.
> surely as far as the carrier is concerned, all traffic from the mobile device is the same
Going on a bit of a tangent, but deep packet inspection can identify packets routed using NAT, so if the phone is operating as a typical hotspot it would be identifiable by your carrier. Carriers in the USA used to block / denylist / charge extra for tethering using this exact approach.
DPI can refer to inspecting beyond just the headers, but since it's more of a marketing term than a technical one, you could also say you're "deeply inspecting" the IP headers of a packet and no-one would show up to arrest you for bad terminology.
Anyway, one way to detect NAT is to observe different TTLs originating from one device. Is that deep inspection? Probably depends on who you ask. The fact that you have to track information across multiple packets counts for something, though.
Off the top of my head I wouldn't really expect there to be much value in a MITM inspection of the contents of HTTP traffic for the purposes of NAT detection. You could probably come up with some scenarios in which it might be possible, but I'd content those scenarios aren't very practical. Easier to compare TTLs between packets, say, or track connections to known OS "phone home" destinations. While these just use information from the IP layer, they're stateful observations requiring comparisons across multiple packets, and that might count for something.
One way to detect a shitty carrier service, though, is that they're inspecting your traffic for "good" or "bad" uses of their service, because that is a good indicator that they're not just a carrier. I call it Dickish Practices Identification, or DPI.
DPI is distinct from TLS MITM (though many enterprise devices offer both).
The delineation here is between "shallow" packet inspection (which basically nobody refers to because it's just a normal part of networking), where network devices look at just the bits of the packets they need to route / NAT / etc them appropriately.
DPI can tell a ton of things without needing to MITM encrypted layer 7 traffic.
A boring example is that you can tell TLS from OpenSSH traffic just by seeing the initial handshake. sslh ( https://github.com/yrutschle/sslh ) takes advantage of this on the server side to let you run both on the same port.
A less boring example is identifying OpenVPN, Wireguard, etc traffic regardless of what port they're run on, to enable blocking VPN traffic on a network.
At one point it was definitely not so deep... carriers were literally looking at the IP TTL and seeing whether it was a recognised value from the phone or a few hops less than one of the common defaults, in which case it was considered tethering traffic.
You could spoof it by finding out your mobile's TTL, overriding the TTL in the connecting device to be one higher than the mobile.
I recently switched to a carrier (Fido/Rogers in Canada). My plan limits hotspot by disabling the hotspot settings on ios. However, I was able to enable it again by changing the access point name.
On android, there is an OS-level feature that checks the cell tower to verify if you're allowed to create a hotspot. It runs whenever you try to enable the hotspot feature. On rooted systems, you can disable this check. There are also apps that let you run a hotspot without using the OS feature, bypassing the check.
I believe there’s some stuff like that for commercial things. One project I worked on used an ‘IoT portal’ for cloud based telemetry (at the customer’s request) and we had to get a special SIM card for it (although I don’t know if this is still needed.)
You could say the same about Codex (and other tooling). Opus as a model is market leading (trading blows with the greatest that OpenAI is peddling), but there will be a reckoning when open weight models are good enough - and I'd argue we are almost there with some of the latest releases. If you hook up the latest OpenAI models to something like OpenCode, its a taste of what an open harness with a powerful model (outside of a providers ecosystem) will be able to offer developers in the future.
> there will be a reckoning when open weight models are good enough
Will you have the hardware to run them? Perhaps. Will enough of Anthropic's/OpenAI's large enterprise customers have the hardware to run them and the money/desire to have their own internal teams set up and maintain them?
Given your attitude, this comment is probably futile, but here goes nothing.
Your attitude here, to give a somewhat more illustrative automotive example, is akin to shunning many modern safety devices, standards and common sense. Driving on bare tyres is fine pretty most the time when sunny, until the road is wet, upon which you will likely end up in a ditch. Same deal with seatbelts, where you're fine for >99% of the time, until your knees end up sandwiched in the windscreen after an accident. Not to mention ABS, AEB, and a whole slew of other safety advancements.
You can keep driving your '70s wagon with bench seats and no seatbelt, no one will stop you. But when your banking details are sniped or your system is subject to a cryptolocking attack and you have to deal with the subsequent inconvenience/crisis, you know why.
If you're going to adopt "but it hasn't happened to me" attitude, you should drop the "just SHUT THE FUCK UP" attitude in your post and start ignoring those comments instead, since the people telling you to upgrade are plainly, objectively correct.
You don't need to use Windows at all to have a modern and secure computing platform, BTW. Once ads started appearing in Windows, it was clear they abandoned all reason for madness. Any power user using it as their primary OS is just asking for it at this point.
Wow; this is the first I've seen someone else describe "geometric nightmares". You're spot on in that they're "hard to describe" - they used to happen very frequently when I was younger and could never explain them.
Bicarbonate Soda powder in the litter box (dumped in and shaken around) entirely eliminated any smell of urine, at least with our two bengals. We started looking into odour treatments, we were tipped off by another savvy shopper at the pet store. Became part of our litter box routine very early on. My backyard science hypothesis is that it reacts with the odour-causing compounds in the urine (urea or uric acid?), which neutralises the smell.
I own a BYD: this is not true. The key is not hinged; rather, the entire mechanical key pulls out when a small clip is unlatched near the top of the assembly (you can see it in the CT). I assume the circular hinge-looking mechanism in the CT is just a by product of the plastic/metal weld process.
Nonetheless: very cool tech demo!
reply