It's already been beaten to death up-thread. The benefits are things like more efficient space utilization and improved aerodynamics. The cost is that something that doesn't happen very often is less convenient. For the majority of car owners who were never going to change their bulbs anyway, there is basically no cost at all. I think that most "reasonable people" have no idea what is required to change their bulb, as galling as it may be for you. Calling it a safety concern is just about as hyperbolic as it gets. Seriously, how often do you blow a bulb? While driving? In a snow storm? If this is your number one issue, go ahead and get yourself a fifty year old chevy. It'll be a death trap in that snowstorm in a lot of ways, but it'll be really easy to change the headlight. (Not actually true: it required a screwdriver, and the screw was likely corroded and a PITA to remove in the dark on the side of a road. Even 50 years ago most people didn't really care about this issue.)

But your point is basically "it shouldn't because I say so", which isn't really compelling. Who cares if it's many hours of driving? Most of the time if I lose a headlight I'm only really sure that it's out when I get to the garage and confirm that there's only one bright spot on the wall; there is sufficient redundancy in the system that driving on a single light is a non-event. In a case where it's really, really, dark and you really can't see well enough on one bulb, the odds are that the bright is still working fine. The odds that the second light will immediately go and that you'll be driving with no regular light is significantly less than the odds that the janky bulb stuff in the glove compartment or rattling in the trunk will have failed due to rough handling. This is simply a non-issue for any reasonable person, even if it really pisses you off.

I used to replace in pairs, don't anymore. (The bare halogens are best just left alone. On my current car, the left bulb lasted 6 years longer than the right.)

The one in the trunk is likely to fail from rattling around in the trunk.

And regardless of whether I had a spare bulb, I'd never stop on the side of the road to change it, I'd just drive on the remaining light until a more convenient time.

I meant they come in pairs on the front of the car. I generally buy them one at a time. If you replace headlights at a rate that requires you to buy them in bulk, you may be installing them improperly.

Hmm. Seems to me it's also good for the following points of view:

1) Miniaturization
2) Reduced cost and/or power consumption via increased integration
3) Improved ergonomics (case design not dictated by repair requirements)
4) Aerodynamics
5) Durability (repairability generally requires additional access points, fasteners, etc., which are themselves points of failure)

Or maybe there are no rational reasons to design things in way that's hard to repair, and it's all just a big conspiracy.

Actually, I did resolder my washing machine control board. (It was a victim of the early ROHS solder that tended to develop mechanical fractures.)

Who the heck replaces a headlight on the side of the road in the dark? You'd have to 1) have the lightbulb and 2) (probably because of #1) already be down one headlight (they do come in pairs). The optimal solution would be to just get the bulb replaced when it burns out rather than being a lazy SOB and driving around with a bulb in the trunk without actually installing it.

Replacing a screen makes economic sense for only a vanishingly small period of time, after which it's cheaper to ebay an entire phone than to procure the parts. Some people want to master the skill of changing such things out, just as there are people who want to master the skills of flint knapping or making homespun fabric. But that's just because they want to, not for any practical reason.

Or you can save the expense and skip the second factor altogether--which is an acceptable risk for almost everyone.

Side note: a second factor token isn't buying much for the attacks we're seeing in the real world. (Compromised endpoint; and no, it doesn't take personal targeting for someone to go active once a user on a compromised host has been identified as using a bank with a scripted attack pattern.) What you really want to stop theft in that scenario is an out of band channel, like SMS confirmation. But then you've got a different set of problems with mobile malware potentially being able to spoof that. Picking just one attack vector, choosing an arbitrary mitigation, then criticizing the banks for implementing the mitigation in too stringent a fashion because your arbitrary standard is "good enough" seems...myopic at best.

You can add a petty subjective clause if you want to, but the point remains--choose the tool that's right for the job you're trying to do.

And crap code or not, it's probably keeping more accurate time than the NTP server that you wrote. ;-)

The NTP people are generally more concerned about accurate & precise network time than about security. If security is your goal (and you're willing to compromise on highly accurate time) you're almost certainly better off with a SNTP solution intended to be simple and secure.

Note that most machines running OSX would be vulnerable to spoofed packets from the same IP (the apple NTP server)...

Firewalls which do stateful inspection of NTP conversations are exceedingly rare. So if you follow the normal practice and have a "stateful" UDP port open on the firewall to a given external NTP server, it's not possible for the firewall to distinguish between a response packet from the external NTP server and a query packet spoofed to appear to be originating from the external NTP server. That is, a client will be potentially vulnerable to spoofed packets from any IP it uses as a server.

It's nice that you think you've managed to define a rigid standard of what risk is acceptable to everybody, but I'm not sure that's actually true.

Of course, this old urban legend ignores the reality of different rail gauges. There maybe some link there, but it's pretty darn tenuous.