You're assuming, of course, that those who write the regulations come from this relatively rare species of intelligent people. The problem is, we have no way to guarantee this. And we run the risk of codifying in regulation something remarkably stupid instead.
I'm not suggesting not to use regulation. I'm suggesting that concluding we should use technically competent technocrats because there is a lack of technically competent people--especially in a world which seems to discount technical competence--runs the risk of creating single points of failure.
Pilots at those airports simply revert to the rules surrounding uncontrolled airports--which is to coordinate with other pilots at the same airport on the tower frequency in order to work out (according to some well defined rules) who has landing and takeoff priority.
It's still a valid question to respond to, if only because for every person who steps up to the plate asking questions to alleviate their ignorance, there are a hundred others out there implementing authentication on various public web sites who remain seeped in their own ignorance.
And programmers are an egotistical lot: when was the last time you ever told a programmer "leave that to the experts" and didn't get "fuck you, asshole; I know what I'm doing!!!" as a response?
And this is different from what I described (with the exception of tossing in a separate constant component of the SALT not stored in the database) how, exactly?
"Use bcrypt. Just use bcrypt. Or PBKDF2 if you must. But really bcrypt. General hash (MD, SHA) != Cryptographic hash function. All that extra cleverness that you're doing with UUIDs is superfluous if you just use a proper HASH function (did I mention bcrypt?)."
The purpose of using a separate per-user token is so that when (not "if") someone takes your database, password similarity won't jump out at them. Meaning if a bunch of users use "123456" as their password, they won't be hashed to the same value in the database.
You have to assume if someone steals your database they're not stealing a single user record, but your entire database of 5 million users, and they now have 5 million data points in order to help them reverse engineer which hashing function was used. And even the best cryptographic one-way hashing function will hash the same input and generate the same output each time--meaning if 10,000 of your 5 million users used "123456", well, it will show up as 10,000 identical fields, giving you a hint as to how things are encrypted.
If you use a one way hash that has been properly salted (i.e., HASH(SALT + password) ), then you should never be able to retrieve forgotten passwords, ever. If you can retrieve a lost password for a user, then you've screwed it up, because if you can recover a lost password, someone who scraped your database can recover a lost password.
The worst, by the way, are web sites which require you to pick a super-secure password (at least 12 characters long, must contain punctuation, both upper and lower case letters, a number character, an Egyptian hieroglyph, and must not match the last 15 passwords used in the past and must be changed ever 30 days)--then stores the password and password history as plain text in the user database. Those are the guys I'd love to murder in cold blood.
Personally I've always liked using some element of a user record attribute as part of the SALT--such as having a UUID associated with each user record that becomes part of the salt for the hash (i.e., HASH(SALT + password + UUID) )--because this means if someone does scrape your database it's computationally a little more difficult to reverse engineer the passwords in the database because even a bunch of people use "123456" as their password, the hashes will be different for each of those users. Of course the UUID must never change or else you'll lock your users out.
I'm also a fan of the POP3 protocol's APOP authentication mechanism, where sending credentials over the 'net requires two transactions: (1) obtaining a unique token for that session, then (2) hashing the password against that token to transmit to the back end. Of course this means you wind up hashing the plain text password *twice*: since you don't have the password on the back end (but its hash) you can only compare against HASH(TOKEN + hashed_password), and on the front end you wind up calculating HASH(TOKEN + HASH(SALT + password + UUID) ). But that requires a lot of work in the client.
Simply sending HASH(SALT + password + UUID) rather than hashing the hash with an additional token means you're subject to a replay attack, where a third party could listen in on the conversation and simply replay the login packet you send to connect to the server.
And while I know a lot of folks claim that all of this is mitigated by using SSH, it doesn't protect against man-in-the-middle attacks, including incidental man-in-the-middle attacks created by certain proxy gateways which use their own certs in order to decrypt HTTP traffic to sniff for viruses or enforce corporate guidelines for acceptable use.
Ultimately security won't stop the most determined hackers; you're not stopping the NSA, for example. But you can stop the script kiddies and disgruntled employees by taking some precautions--such as never storing sensitive information in a database (like credit cards) unencrypted, and using one-way hashes to store passwords.
Oh, and as a footnote: unless you have a Ph.D. in cryptography, don't write your own random functions or hash functions. Yes, I've seen it in the field. Instead, use a cryptographically secure hash function. Heck, even MD-5 is going to be better than anything you try to roll on your own.
Okay, an internet connected thermostat does add functionality. An internet connected fire detector and an internet connected home security system also makes sense. (Though if you're working on a home security system that hooks up to the Internet and you don't think about software security, you're an idiot who needs to be put into protective custody and fed by a nurse so you don't accidentally poke your eyes out while eating with a plastic fork.)
But why do I need an internet connected oven, refrigerator, or toaster? Do I need an internet connected coffee maker? An internet connected microwave? What value do they add, really? Notifications?
Time is also a cost; if it takes me 20 minutes to drive somewhere by car but an hour to get there by mass transit, then the equation makes no sense. If, on the other hand, you live somewhere where driving is impractical and an hour drive can be replaced by 20 minutes on mass transit, then clearly I'd take mass transit almost regardless of the cost.
Mac Pro (Late 2013) w/ 3.5GHz 6-core Xeon E5, 64GB RAM, 1 TB of Flash disk space.
Bought the extra RAM configuration so I could crunch OpenStreetMap data quickly. Turns out more RAM is better than more CPU horsepower, though the 3.5GHz E5 isn't really that shabby.
Make sure that they run whatever cable you decide to run (ethernet, fiber, whatever) in conduit, ideally with junction boxes on a relatively regular basis (at bends, etc), so it is easy to draw new wire through when you need to.
Yes, the electrician will say "you don't need to do that; that's silly." Ignore him. Do it.
I just recently moved into a house with ethernet run through to all of the rooms from an access point in the basement. Unfortunately over the years some of the runs have deteriorated--but sadly, the ethernet wire was simply threaded through holes in the studs, making it virtually impossible to pull new wire through. Had it been drawn through relatively large conduit, and had there been boxes on a regular basis, it would take just a few minutes to draw a new wire.
That also goes for conduits where you may want to put a big screen TV on the wall, low voltage systems (like door bells), and other runs where you may want to add something new (like in-home speakers or whatever). I know it's impossible to plan for everything, but at least you'll have a fighting chance when some new technology comes around (or something in the wall breaks), that it can be easily replaced without having to tear up a whole lot of drywall.
According to AirNav, La Guardia handles around 1013 aircraft operations a day; that's 1013 takeoffs and landings per day. Compare to JFK, which handles 1232 aircraft operations a day with twice as many runways, or Newark, with 1098 aircraft operations a day.
The airport might suck and may or may not be inconvenient, but it is handling far more traffic than can be diverted to another existing airport. You could expand another existing airport to handle the excess traffic--but where? Teterboro? Caldwell in Essex County? Long Island Mac Arthur?
And the entire industry is moving away from long haul flights to shorter regional hops, meaning traffic operations are only going to increase. So assuming you can just divert all the flights to JFK and Newark isn't going to work; split the number of flights between the two and now you have two airports handling about the same amount of traffic as LAX, with 1741 flights/day. So even if we assume those airports can handle the increase in traffic, that pretty much will max out both airports and prevent future expansion.
Hong Kong International took nearly a decade to construct, in a regulatory environment which makes it easy to steamroll in large infrastructure projects. So constructing a new airport near Rikers Island is not going to happen over a weekend.
And if you did go the Hong Kong route, you may be better off spending the money, moving everything off Rikers Island, and expanding the airport by paving Rikers and adding two additional runways, modernizing La Guardia, and extending the subway system to run out to the terminals there.
That was pilot error caused by a pilot who failed to keep the proper speed on approach to an airport where the ILS glide slope was out of service. That could have happened at any airport. Fortunately it did not happen at an airport where there were tall buildings along the flight path, otherwise the damage would have been far worse.
Where we moved to in North Carolina, we're only served by two utilities: AT&T (for internet/phone/TV) and Duke Progressive (for electricity). We use electric heating--which is expensive, and while our neighborhood will be getting natural gas in the next few months, it makes no economic sense for us to replace our central heating system with gas. (The payoff exceeds the lifespan of the HVAC already installed.)
I have to admit, the primary reason for not getting solar where we've lived in Los Angeles and now in Raleigh is that it didn't make a lot of economic sense. But as solar cell prices drop, having a battery-backed solar system on my house starts to sound more promising--especially after the last storm which knocked out our power for a couple of days.
Since we are on a well and septic tank, if we can get most of our power from solar then we can pretty much be self-sufficient if there is a major disruption in the future--and that's worth a premium over what we now pay for electric service.
Really, what's happening is that they're performing repeated concatenations of various length strings--an operation that eventually becomes O(m*n) time, with m being the length of the string and n being the number of strings. (Concatenating strings in Java requires a new string to be created, then the contents of the two source strings copied into the new destination.) Appending a file, on the other hand, is only an O(n) operation, but has a very large constant time associated with it. So, in essence: TL;DR: O(n**2) operations can be slower in memory than O(n) operations on disk for large values of n.
The real lesson is that you should understand what's going on underneath the hood. And in this case, if you're doing a lot of string concatenation operations in Java, you probably should be using the StringBuilder class. I mean, after all, that's why there are multiple ways to do the same thing in Java (like ArrayList verses LinkedList): each offers different performance characteristics, and at the fringes performance characteristics can kill your application.
Rolex, in fact, hand-manufactures its own movements. Some processes of the manufacturing process do use some degree of automation, and of course a number of jigs are used during the assembly process. But they are hand-built movements built internally by Rolex.
The reason why people think Rolex outsources their movements is because Rolex doesn't talk much about their movements, and because Rolex used to use Zenith watch movements in some of their watches, such as the Daytona. (Since 2000, the Daytona has used an in-house movement--and I suspect this move to bring all their movements in-house is what drove Zenith to release their own complete watches.)
Omegas, on the other hand, mostly uses mass-manufactured ETA movements rather than using movements made in-house. While ETA movements are certainly of a much higher quality than mass-manufactured movements from China, they are still basically mass-produced watch movements.
Try "thousands", if the movement is built in-house and has more than a couple of complications. Ah, hell; try hundreds of thousands for a custom watch movement with more than a handful of complications--mostly due to engineering costs of designing the movement, which can take years. And when you get to the extreme high end of the watch movement market, they start becoming small analog computers, such as this Patek Philippe pocket watch, which has a complication which calculates the sidereal day, and was constructed in 1933. Or this Jaeger-LeCoultre, which consists of over 1400 individual parts and 26 separate complications.
Here's the thing about luxury watches: for women, you can wear necklaces, wrist bands, rings and earrings. But for men, the only pieces of jewelry that a man can wear (and get away with it) is cufflinks, a tie clip and a luxury watch. And if you're not wearing a shirt with french cuffs, or wearing a tie, then all that is left is the watch.
So basically a luxury watch is jewelry. Functional jewelry, but jewelry all the same. And like all jewelry, if its taken care of you can inherit it from your grandparents (as my wife inherited some pieces), you can receive it when you are young and still wear it when you're old, and you can pass it down to your grandchildren.
When you start looking at luxury watches, you find there are two types: those which use an in-house built movement built by craftsmen who sweat the details and who create all sorts of intricate complications which do interesting things (like keep accurate time, provide a stopwatch function, show the phase of the moon, the day of the month, the month of the year), and those who buy an off-the-shelf movement and wrap it in gaudy jewelry.
From what I've read (I'm not a collector but I'd like to be one someday if I ever really strike it extremely rich, because mechanical wrist watches fascinate me no end), watches from watchmakers who build their own movements are highly respected. Watches from watchmakers who buy their movements from third parties, however, are not very well respected. And the worst are those who use quartz movements: essentially an electric powered watch movement regulated by a small oscillator crystal. Like about 1/3rd of Tag Heuer's product line, many running up into the 10's of thousands, which horticulturally have more in common with a cheap Casio than with an A. Lang & Sohne.
This is why I think luxury smart watches will be an unmitigated disaster. Sure, some people will buy them--because some people have more money than God, and to be able to show off a $10,000 smart watch that you're just going to toss away in a couple of years when the electronics are out of date would be the height of "one upping the Joneses." But I cannot see them being any more interesting to someone fascinated by mechanical watches than a quartz Tag Heuer--it's the sort of watch someone with no sense of connection to the past or any sense of connection to the tradition of hand-crafted watches would shove in your face to exclaim how much better they are than you.
Slashdot Mirror
You're assuming, of course, that those who write the regulations come from this relatively rare species of intelligent people. The problem is, we have no way to guarantee this. And we run the risk of codifying in regulation something remarkably stupid instead.
I'm not suggesting not to use regulation. I'm suggesting that concluding we should use technically competent technocrats because there is a lack of technically competent people--especially in a world which seems to discount technical competence--runs the risk of creating single points of failure.
Pilots at those airports simply revert to the rules surrounding uncontrolled airports--which is to coordinate with other pilots at the same airport on the tower frequency in order to work out (according to some well defined rules) who has landing and takeoff priority.
Some information here: FAA: Operations at non-towered airports
It's still a valid question to respond to, if only because for every person who steps up to the plate asking questions to alleviate their ignorance, there are a hundred others out there implementing authentication on various public web sites who remain seeped in their own ignorance.
And programmers are an egotistical lot: when was the last time you ever told a programmer "leave that to the experts" and didn't get "fuck you, asshole; I know what I'm doing!!!" as a response?
And this is different from what I described (with the exception of tossing in a separate constant component of the SALT not stored in the database) how, exactly?
"Use bcrypt. Just use bcrypt. Or PBKDF2 if you must. But really bcrypt. General hash (MD, SHA) != Cryptographic hash function. All that extra cleverness that you're doing with UUIDs is superfluous if you just use a proper HASH function (did I mention bcrypt?)."
The purpose of using a separate per-user token is so that when (not "if") someone takes your database, password similarity won't jump out at them. Meaning if a bunch of users use "123456" as their password, they won't be hashed to the same value in the database.
You have to assume if someone steals your database they're not stealing a single user record, but your entire database of 5 million users, and they now have 5 million data points in order to help them reverse engineer which hashing function was used. And even the best cryptographic one-way hashing function will hash the same input and generate the same output each time--meaning if 10,000 of your 5 million users used "123456", well, it will show up as 10,000 identical fields, giving you a hint as to how things are encrypted.
If you use a one way hash that has been properly salted (i.e., HASH(SALT + password) ), then you should never be able to retrieve forgotten passwords, ever. If you can retrieve a lost password for a user, then you've screwed it up, because if you can recover a lost password, someone who scraped your database can recover a lost password.
The worst, by the way, are web sites which require you to pick a super-secure password (at least 12 characters long, must contain punctuation, both upper and lower case letters, a number character, an Egyptian hieroglyph, and must not match the last 15 passwords used in the past and must be changed ever 30 days)--then stores the password and password history as plain text in the user database. Those are the guys I'd love to murder in cold blood.
Personally I've always liked using some element of a user record attribute as part of the SALT--such as having a UUID associated with each user record that becomes part of the salt for the hash (i.e., HASH(SALT + password + UUID) )--because this means if someone does scrape your database it's computationally a little more difficult to reverse engineer the passwords in the database because even a bunch of people use "123456" as their password, the hashes will be different for each of those users. Of course the UUID must never change or else you'll lock your users out.
I'm also a fan of the POP3 protocol's APOP authentication mechanism, where sending credentials over the 'net requires two transactions: (1) obtaining a unique token for that session, then (2) hashing the password against that token to transmit to the back end. Of course this means you wind up hashing the plain text password *twice*: since you don't have the password on the back end (but its hash) you can only compare against HASH(TOKEN + hashed_password), and on the front end you wind up calculating HASH(TOKEN + HASH(SALT + password + UUID) ). But that requires a lot of work in the client.
Simply sending HASH(SALT + password + UUID) rather than hashing the hash with an additional token means you're subject to a replay attack, where a third party could listen in on the conversation and simply replay the login packet you send to connect to the server.
And while I know a lot of folks claim that all of this is mitigated by using SSH, it doesn't protect against man-in-the-middle attacks, including incidental man-in-the-middle attacks created by certain proxy gateways which use their own certs in order to decrypt HTTP traffic to sniff for viruses or enforce corporate guidelines for acceptable use.
Ultimately security won't stop the most determined hackers; you're not stopping the NSA, for example. But you can stop the script kiddies and disgruntled employees by taking some precautions--such as never storing sensitive information in a database (like credit cards) unencrypted, and using one-way hashes to store passwords.
Oh, and as a footnote: unless you have a Ph.D. in cryptography, don't write your own random functions or hash functions. Yes, I've seen it in the field. Instead, use a cryptographically secure hash function. Heck, even MD-5 is going to be better than anything you try to roll on your own.
Okay, an internet connected thermostat does add functionality. An internet connected fire detector and an internet connected home security system also makes sense. (Though if you're working on a home security system that hooks up to the Internet and you don't think about software security, you're an idiot who needs to be put into protective custody and fed by a nurse so you don't accidentally poke your eyes out while eating with a plastic fork.)
But why do I need an internet connected oven, refrigerator, or toaster? Do I need an internet connected coffee maker? An internet connected microwave? What value do they add, really? Notifications?
Time is also a cost; if it takes me 20 minutes to drive somewhere by car but an hour to get there by mass transit, then the equation makes no sense. If, on the other hand, you live somewhere where driving is impractical and an hour drive can be replaced by 20 minutes on mass transit, then clearly I'd take mass transit almost regardless of the cost.
Mac Pro (Late 2013) w/ 3.5GHz 6-core Xeon E5, 64GB RAM, 1 TB of Flash disk space.
Bought the extra RAM configuration so I could crunch OpenStreetMap data quickly. Turns out more RAM is better than more CPU horsepower, though the 3.5GHz E5 isn't really that shabby.
Sorry, you're right; was thinking of the crawl space under my old house.
Make sure that they run whatever cable you decide to run (ethernet, fiber, whatever) in conduit, ideally with junction boxes on a relatively regular basis (at bends, etc), so it is easy to draw new wire through when you need to.
Yes, the electrician will say "you don't need to do that; that's silly." Ignore him. Do it.
I just recently moved into a house with ethernet run through to all of the rooms from an access point in the basement. Unfortunately over the years some of the runs have deteriorated--but sadly, the ethernet wire was simply threaded through holes in the studs, making it virtually impossible to pull new wire through. Had it been drawn through relatively large conduit, and had there been boxes on a regular basis, it would take just a few minutes to draw a new wire.
That also goes for conduits where you may want to put a big screen TV on the wall, low voltage systems (like door bells), and other runs where you may want to add something new (like in-home speakers or whatever). I know it's impossible to plan for everything, but at least you'll have a fighting chance when some new technology comes around (or something in the wall breaks), that it can be easily replaced without having to tear up a whole lot of drywall.
You're missing my point, which is that PayPal did not include an 'opt-out' mechanism.
Apparently PayPal has decided to say "fuck the law."
"Opt-out."
How cute...
Didn't you know? There is no "opt-out."
Well, you could always change your phone number to 888-221-1161, which is Paypal's customer support number.
According to AirNav, La Guardia handles around 1013 aircraft operations a day; that's 1013 takeoffs and landings per day. Compare to JFK, which handles 1232 aircraft operations a day with twice as many runways, or Newark, with 1098 aircraft operations a day.
The airport might suck and may or may not be inconvenient, but it is handling far more traffic than can be diverted to another existing airport. You could expand another existing airport to handle the excess traffic--but where? Teterboro? Caldwell in Essex County? Long Island Mac Arthur?
And the entire industry is moving away from long haul flights to shorter regional hops, meaning traffic operations are only going to increase. So assuming you can just divert all the flights to JFK and Newark isn't going to work; split the number of flights between the two and now you have two airports handling about the same amount of traffic as LAX, with 1741 flights/day. So even if we assume those airports can handle the increase in traffic, that pretty much will max out both airports and prevent future expansion.
Hong Kong International took nearly a decade to construct, in a regulatory environment which makes it easy to steamroll in large infrastructure projects. So constructing a new airport near Rikers Island is not going to happen over a weekend.
And if you did go the Hong Kong route, you may be better off spending the money, moving everything off Rikers Island, and expanding the airport by paving Rikers and adding two additional runways, modernizing La Guardia, and extending the subway system to run out to the terminals there.
That was pilot error caused by a pilot who failed to keep the proper speed on approach to an airport where the ILS glide slope was out of service. That could have happened at any airport. Fortunately it did not happen at an airport where there were tall buildings along the flight path, otherwise the damage would have been far worse.
Was it really an out of memory issue, or was it fundamentally because the U-2 was flying higher than 65,535 feet?
Mine's more.
Where we moved to in North Carolina, we're only served by two utilities: AT&T (for internet/phone/TV) and Duke Progressive (for electricity). We use electric heating--which is expensive, and while our neighborhood will be getting natural gas in the next few months, it makes no economic sense for us to replace our central heating system with gas. (The payoff exceeds the lifespan of the HVAC already installed.)
I have to admit, the primary reason for not getting solar where we've lived in Los Angeles and now in Raleigh is that it didn't make a lot of economic sense. But as solar cell prices drop, having a battery-backed solar system on my house starts to sound more promising--especially after the last storm which knocked out our power for a couple of days.
Since we are on a well and septic tank, if we can get most of our power from solar then we can pretty much be self-sufficient if there is a major disruption in the future--and that's worth a premium over what we now pay for electric service.
Really, what's happening is that they're performing repeated concatenations of various length strings--an operation that eventually becomes O(m*n) time, with m being the length of the string and n being the number of strings. (Concatenating strings in Java requires a new string to be created, then the contents of the two source strings copied into the new destination.) Appending a file, on the other hand, is only an O(n) operation, but has a very large constant time associated with it. So, in essence: TL;DR: O(n**2) operations can be slower in memory than O(n) operations on disk for large values of n.
The real lesson is that you should understand what's going on underneath the hood. And in this case, if you're doing a lot of string concatenation operations in Java, you probably should be using the StringBuilder class. I mean, after all, that's why there are multiple ways to do the same thing in Java (like ArrayList verses LinkedList): each offers different performance characteristics, and at the fringes performance characteristics can kill your application.
If you were as arrogant as you think you are you wouldn't have condescended to reply!
So you're saying that my reply saying I'm arrogant cannot possibly be arrogant because I replied?
Ummmm...
No, I'm an arrogant asshole, not a crass one.
Rolex, in fact, hand-manufactures its own movements. Some processes of the manufacturing process do use some degree of automation, and of course a number of jigs are used during the assembly process. But they are hand-built movements built internally by Rolex.
The reason why people think Rolex outsources their movements is because Rolex doesn't talk much about their movements, and because Rolex used to use Zenith watch movements in some of their watches, such as the Daytona. (Since 2000, the Daytona has used an in-house movement--and I suspect this move to bring all their movements in-house is what drove Zenith to release their own complete watches.)
Omegas, on the other hand, mostly uses mass-manufactured ETA movements rather than using movements made in-house. While ETA movements are certainly of a much higher quality than mass-manufactured movements from China, they are still basically mass-produced watch movements.
Try "thousands", if the movement is built in-house and has more than a couple of complications. Ah, hell; try hundreds of thousands for a custom watch movement with more than a handful of complications--mostly due to engineering costs of designing the movement, which can take years. And when you get to the extreme high end of the watch movement market, they start becoming small analog computers, such as this Patek Philippe pocket watch, which has a complication which calculates the sidereal day, and was constructed in 1933. Or this Jaeger-LeCoultre, which consists of over 1400 individual parts and 26 separate complications.
I own a Rolex DateJust in Gold and Stainless Steel, and someday I'd like to own a Jaeger-LeCoultre Master Ultra Thin Moon 39 in Stainless Steel, as well as a Breitling Navitimer 01. For my father's 70th birthday we bought him a Navitimer 01, which he just loves. (My father and I are both private pilots.)
Here's the thing about luxury watches: for women, you can wear necklaces, wrist bands, rings and earrings. But for men, the only pieces of jewelry that a man can wear (and get away with it) is cufflinks, a tie clip and a luxury watch. And if you're not wearing a shirt with french cuffs, or wearing a tie, then all that is left is the watch.
So basically a luxury watch is jewelry. Functional jewelry, but jewelry all the same. And like all jewelry, if its taken care of you can inherit it from your grandparents (as my wife inherited some pieces), you can receive it when you are young and still wear it when you're old, and you can pass it down to your grandchildren.
When you start looking at luxury watches, you find there are two types: those which use an in-house built movement built by craftsmen who sweat the details and who create all sorts of intricate complications which do interesting things (like keep accurate time, provide a stopwatch function, show the phase of the moon, the day of the month, the month of the year), and those who buy an off-the-shelf movement and wrap it in gaudy jewelry.
From what I've read (I'm not a collector but I'd like to be one someday if I ever really strike it extremely rich, because mechanical wrist watches fascinate me no end), watches from watchmakers who build their own movements are highly respected. Watches from watchmakers who buy their movements from third parties, however, are not very well respected. And the worst are those who use quartz movements: essentially an electric powered watch movement regulated by a small oscillator crystal. Like about 1/3rd of Tag Heuer's product line, many running up into the 10's of thousands, which horticulturally have more in common with a cheap Casio than with an A. Lang & Sohne.
This is why I think luxury smart watches will be an unmitigated disaster. Sure, some people will buy them--because some people have more money than God, and to be able to show off a $10,000 smart watch that you're just going to toss away in a couple of years when the electronics are out of date would be the height of "one upping the Joneses." But I cannot see them being any more interesting to someone fascinated by mechanical watches than a quartz Tag Heuer--it's the sort of watch someone with no sense of connection to the past or any sense of connection to the tradition of hand-crafted watches would shove in your face to exclaim how much better they are than you.
You know: crass assholes.
"Feed into a small molten salt reservoir buried in the yard to pull out of at night?"
Who do you think I am? Dr. Evil?
On the other hand, it may be useful to have a molten salt reservoir in my back yard, so I can dispose of the bodies...