I personally really dislike the screen ones. They're slower, less reliable and the location is unnatural.

If something like Nepenthes added poisoned pages to it's tarpit then a small number of users can just poison all LLMs?

They seem to get more abuse over time i.e. MACs are how a car is uniquely identified and authenticated with fast charging CCS networks for Autocharge.

A regular SIM: you just pop a SIM card into your phone and it just God damn works.

But eSIMs? I've used eSIMs from five carriers in three different countries and every time there is some issue:

* "Oh you need our god awful app to install an eSIM" (of course I couldn't easily download it because Google play geo hides apps).

* "If your phone is stolen overseas you can simply use this QR barcode again to register an eSIM to a new phone" (I couldn't).

* "Works with all phones". (It didn't because phone manufacturers have to bake Telco specific data into your phones firmware. Not supported? You're shit out of luck).

I could go on..

The fact that there are now privacy and security issues is not surprisingly at all. This isn't teetching issues. The drafters of the eSIM standard should be publicly flogged.

It's part of why the next crew dragon mission is being delayed, it needs to use the docking port currently occupied by Starliner (and Starliner can't leave until Boeing updates and uploads software for full autonomous operations).

STV is used for the Australian Federal Senate.

The federal lower chamber (House of Representatives) uses optional preferential voting for candidates in a federal electorate.

I'm not sure if NZ is a fair comparison as it uses MMP, which is deliberately designed to favour multiple parties forming coalitions, not independents.

Part of the reason for this rule was that they:

1) OEMed their products.

2) Sold products that could be used in complex and bespoke CAN networks with goodness knows what else.

3) There was a chance of interfering with Marine VHF radio which is used for emergencies. The EU rules were (still are) not actually strict enough for preventing interference with that band.

If you don't want to hire a consultant then don't. You can do it yourself. Go get a EEE degree and then spend 5-15 years working as a EEE in product development and certification. Then you'll be good to go :)

Or just blind self certify and pay the lawyers, Friendly Spectrum Agency and other spectrum users (like cell phone companies) when they come knocking and asking for damages from you.

Here is a free primer I replied with earlier today: https://news.ycombinator.com/item?id=40926870

Make your test setup as easy as possible.

To expand on that:

1) Realise that you're mostly working with testing technicians NOT engineers. They see all sorts of weird and wild stuff. They often have to parse poorly written and complicated manuals written by engineers who don't have a clue about writing manuals and make poor implicit assumptions about the "target audience".

2) It's frankly, often soul destroying work (hence the churn, especially at the bigger labs). They use the crappy manuals for crappy products (but everyone thinks their product is the bees knees) try and set it all up. Then it doesn't work. Or it fails because the customer didn't do any pre-compliance work and was "hoping it would just pass". Well time is money, now they have to break the setup down because they've wasted 1 hour on the phone to some engineer who doesn't know what's wrong and is trying to trouble shoot through the phone. Now they get to do ALL that again with one else's crappy product.

So how do you make it as easy as possible for them?

1) Your setup should be plug and play and I mean TRULY plug and play. No manual should be required for putting the device into some hacky test state. Get the software engineers to automate it.

Does a button need pushing? Automate it or just remove the requirement somehow.

Does it need wiring up? Nail it all down on a giant piece of ply wood. Zip tie down all the cables. All the dummy loads. Any other devices. The only thing they should need to connect is the power cable.

Does a laptop need to drive it? Automate everything on there. ONE SCRIPT, maybe a menu in there depending on what test they are running. Make the laptop bullet proof. Get a nice laptop that boots and runs fast (not the one at the bottom of the IT donor pile). Give them a mouse to use.

Remove ALL of these barriers. AUTOMATE it ALL. Don't require them to baby sit it. That's a waste of their time.

PLUG AND PLAY.

2) Make it easy for a technician to see if and when the device is working VS it's not working. Don't give them instructions on "open this menu, do this, do that ..." no.

Put a red LED on it and a green one. Don't have one in your product? Be creative, Retrofit something. Have a special test UX on the device. Hell you should have special test firmware as a reference point.

They should be able to, at a single glance, look at the product and know: "Is it still working/running?"

So now imagine you have done all of that effort. Now put yourself in the shoes of that technician. One of the test stands is available early because a crappy product failed. They gaze towards the giant pile of crap they have to get through. Many are a a giant plastic box with tangles of cable, hand written crappy instructions, an IBM thinkpad from 1995 to drive it, no labels on any of the cables ....

... but amongst it they see your PLUG AND PLAY testable product. It's all mounted on a plywood stand, ready to go. There is almost a light from heaven illuminating it, it's so beautiful, it's so easy throw on a test stand and GO (and then do something else).

Guess which one is jumping the queue and going on that test stand? (And time is money remember. A test stand not testing is loosing money).

"I can't imagine having to have each hardware iteration certified by the FCC."

Depending on your device and the magnitude of the changes, this might simply be the reality for you. This is why I always try to tell people that you need compliance at the table from the start or you really risk making life very difficult for yourself. Find yourself a compliance specialist or at least a hardware engineer who is familiar with the regulations.

EDIT: You CAN'T just iterate ad-infinitum for free without consequence like you do for software. This thinking and approach, only works in software land. No where else.

It would be ridiculous to build a house and having the builder iterate on your house over 2-3 years to finish it, no?

The other part of the rules are for human safety. Devices can directly hurt people (like a microwave) or indirectly (like a crappy device that prevented ambulance phone calls going through).

It's as simple as that (and not perfectionism or being mean to the poor software people).

""we're going to teach you how to cheaply get your product to market in a way that respects the spectrum" I'm available to do exactly that for you at my hourly rate :D