Google accounts online can be protected by 2FA, but your Google device is the weak link, because it has access to all your photos and drive documents without authentication once your device is unlocked.
Be sure to use a short screen lock timeout, set your device to lock when the power button is pressed, and make a habit of always pressing it when you are done using your phone. Basically, maximize the odds that if your device is lost or stolen, it will be in a locked state.
As others have mentioned, finger prints can be faked, passwords can be guessed
Fingerprints can be faked, and I don't have any recommendations as to how to mitigate that risk. You could choose not to use biometric authentication, but in most cases I think that's a bad tradeoff, since the convenience of fingerprint auth makes it practical to lock your phone much more aggressively. So, using fingerprint auth increases your risk against attackers who are willing to go to the effort of lifting prints and making gummi fingers, but increases the odds that lazy attackers will find that your phone is locked against them. I think for most people the tradeoffs fall on the side of aggressive locking and use of fingerprint auth.
Passwords (including PIN and pattern) are harder to guess than you might realize. Android has mandated that password matching happen in secure hardware that enforces guess rate limiting since Nougat. I think the mandated rate limiting is a too permissive, but it's enough that without some clues even guessing a four-digit PIN would take months, if not years. If the attacker is that dedicated and focused, odds are that your phone isn't the path of least resistance.
but none of that matters when the phone is stolen if you are missing the token attached to someone's keychain.
Interesting idea. I haven't heard of any demand for phone login 2FA, but it could be a good idea.
(Note that what follows is me thinking out loud; sorry that it's kind of rambling.)
I'm not sure if a BLE token is the right tool, but it might be. I'll look into it (I'm the lead engineer and manager for some of the relevant bits of Android). I think we'd need backup options in case the token were lost or stolen. Maybe on devices with a biometric authenticator, you could unlock with {password|fingerprint} + token, or if you didn't have your token you could unlock with password + fingerprint, so 2FA that way. Or password + fingerprint + face, if devices with both face auth and fingerprint auth become common. Given the brute force mitigation in place for password auth, I'm pretty comfortable with password auth security on Android (even with fairly weak passwords -- barring shoulder surfing attacks), so maybe the token makes sense as a way to strengthen the inherent weaknesses of consumer-device biometric auth.
If it makes sense to require password + token, then perhaps some other backup option could be implemented. Maybe a set of randomly-generated one-time-use passwords like the backup 2FA passwords for Google account auth. In the event you lost your token, you could pull the printed backups out of your wallet and enter one along with your password. Maybe.
And I wonder if we could even go so far as to use this 2FA token as part of Android Keystore authentication-bound key unlocking, as well as for device unlocking. I could see applications wanting to create keys which can only be used if (a) the user has authenticated themselves in the last X minutes and (b) the token is still in range. This is tricky because the secure hardware used to manage keystore keys probably doesn't have access to the Bluetooth stack... but it might be okay if the token presence requirement were enforced by system software rather than secure hardware. Hmm.
As a more-secure alternative to a BLE token, a smartwatch could be used as the token.
Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.
What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.
This is a scary argument.
Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.
Actually, you make a good point. Google in this case has far less power than a traditional CA, because each time you set up a WebAuthN authentication with a web site, you generate a new, unique asymmetric key pair and the site you're authenticating to stores the public key. The Google root is used only at that time, by the web site to verify that the key you've provided is stored in some sort of secure hardware -- and only if they care to verify that (in most cases, I can't think they'll even bother.).
Once the key pair has been generated and the public key stored, Google no longer has any role at all in WebAuthN. They can't use their root key to get the web site to accept a different public key as identifying you.
BTW, to be clear, I should say "we", not "they". I'm the lead engineer for and designer of the Android Keystore attestation that is the root of trust for Android WebAuthN. If you have any questions about how keys are generated, managed, revoked, etc., just ask.
Password-less authentication isn't about security -- it's about control and LACK of security. Google wants to hold the keys to the city.
Nope. Google has no access to any of the keys used.
Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.
What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.
Corrected headline - Android is helping to spread pervasive tracking.
You don't know what you're talking about. The FIDO2 approach to online auth uses a different key to authenticate to every we site and is designed to make it impossible to connect a login to one site with a login to another site (unless user-provided data provides a connection between them).
The easy way to get third party countries to block stolen IMEI's would be for the USA/EU and a few others to get together and simply announce they will stop accepting inbound calls from such networks from say six months from now. Watch them scramble to start the blocking.
I think that would violate several international agreements / treaties. Plus it's like killing butterflies with a sledgehammer.
You really think 60 days is going to stop thief? It's not going to make any difference.
It changes what the thief has to do pretty dramatically. The thief can't just take a pallet of phones off a truck and ship them to Africa, he has to get the phones activated on real user accounts for two months first. That basically means he has to steal them from individual users -- and there are additional obstacles created by user passwords, factory reset protections, etc. All very difficult and risky.
I don't think it's the right solution... but it would basically eliminate supply chain phone theft.
Identity theft is a rather weird thing to complain about.
My guess is that what this is really about is preventing supply chain phone theft. What happens is that phones are stolen while in transit to customers, or out of stores (often by employees), etc., and then shipped to other parts of the world and activated there. There's actually an international clearinghouse for stolen IMEIs, so that theoretically other networks can refuse to allow stolen devices onto their networks. But the destination networks, especially in Africa and Southeast Asia, have little reason to cooperate. Allowing phones to be locked to Verizon's network for 60 days would help with this, because it would ensure that phones stolen before they get activated on a customer account can't be used anywhere (as long as the implementation of the network lock is secure enough).
If my guess is correct, then I kind of understand what they're trying to do... but I think they should just figure out how to secure their supply chain. The inability to network lock was part of the deal when they bought their spectrum so they should deal with it (if you recall; Google was considering becoming a carrier and negotiated a deal with the FCC to buy it, and included a provision in that deal that the spectrum had to be kept open in a couple of ways -- no limitation on tethering and no network locking. Verizon eventually outbid Google and got the 4G spectrum, but the openness requirements attached by Google stayed.)
No. And you forgot to state in your hypothetical that the vehicle in question is dangerous even without the software problems and requires you to be perfectly healthy and agile to get an approximation of a safe ride.
I'm 50 years old and 70 pounds overweight. I find e-scooters to be convenient, fun, cheap and adequately safe urban transportation when I'm traveling. Quicker and less tiring than walking, more convenient, cheaper and more fun than taxi/Uber or renting a car.
I wouldn't use a scooter in bad weather, though. If it's too hot, too cold or too wet, I'll get enclosed transportation. Though I do agree that a scooter widens my tolerance for heat and cold a bit, especially heat.
It wouldn't take more than 2 sentences to include an explanation about ground speed versus air speed. Not even talking about the differences in airspeed at different altitudes and densities, mach, etc. But I guess even that is too much for our technical details-allergic media.
It never occurred to me that anyone would need that explanation. Everyone knows that a tailwind makes you go faster and a headwind makes you go slower. It's utterly obvious that if your engines make you go X mph, and you have a Y mph tailwind, you're going X + Y mph.
Maybe the reporter also thought it was too obvious to waste words on.
Can you find a _single_ reputable physicist or chemist who thinks room temperature superconductors are feasible?
Well, there are these guys. It took 10 seconds of Googling to find that, and there are lots more. If no reputable chemists or physicists believe room temperature superconductors are feasible, there sure are a lot of them wasting their time. The 2016 Nobel Prize in Physics was given to a group of mathematicians and physicists whose research may pave the way towards high-temperature superconductors (as well as a lot more).
Many speculate on the idea
Why do they bother if they all believe it's infeasible? And they clearly do a lot more than just speculate.
but none has demonstrated a practical theory of how to do so.
So your argument is that because no one has achieved it, no one even thinks it's possible? Really?
Given this Navy guy's other patents and the nature of how his invention supposedly works, I'm pretty skeptical that he's done it. I expect that if it's achieved it will be one with some pretty exotic materials and/or complex methods, because if it were easy it would have been done years ago. But assuming it's impossible just because no one has done it is silly.
2018 RHAT revenue was $2.9 billion. Canonical last year had revenues of $125.97 million. That's a 20x multiple.
The market share follows a similar trend.
The market share does not follow a similar trend, not even if you restrict yourself to the server space, and RH barely even registers in the desktop space.
Red Hat has focused on an easier-to-monetize market segment, that's all.
Art is a response from the artist, often provocative, that channels their consciousness into their creation.
I doubt this. I think most art is much more random than that, and that much of the "channeled consciousness" is post-hoc explanation -- often supplied by the early observers at least as much as by the artist.
this fundamentally boils down to free will and thinking we have some magical divine spark inside us, instead of us just being unimaginably complex meat computers. the jury's still out on that one.
Or both. It's also possible that we are unimaginably complex meat computers with a magical divine spark... but that the same spark exists in elementary particles and the meat computer serves to amplify that weak spark into something visible.
As to the core question, whether an AI can be an artist, I think there are a couple of problems with Kelly's argument. The first is that he implicitly assumes that only a human can "be responsive to social necessity", which is tantamount to assuming that no AI can ever understand human social context to the same degree that a human can. I think humans don't understand our social context particularly well, so I don't think it's that much of a stretch to think that an AI could do it as well. Especially since subtle errors in understanding the context may just provoke the strongest reactions from viewers of the art.
The second is the common assumption -- which I think is a mistake -- that artists understand / intend the meaning of their own work. They do to some degree, but I think most of the social contextualization that lends meaning to art happens in the eye / mind of the observer not the artist. Especially among avant-garde artists, I think there are a fair number whose real talent is that their nearly-random acts of creation just happen to touch something in the psyches of many people, and especially in the right kind of people, those who are well-positioned to make the artist famous.
No, they don't. They propose different hypotheses.
The set of validated (by measurement, observation, proof, experiment, reasoning picked apart) hypotheses is what constitutes a theory.
No theory is ever completely proven. Not only is it always possible to get new observations that will contradict a given theory, it's also possible to posit a different theory that predicts contradictory observations which have not yet been made. This means that consensus is always what defines our current notion of scientific "truth" (which is never absolute, so "truth" is really not a good word). For any given broadly-accepted theory there are often individual scientists who take issue with some element of the theory, or even that propose something quite different. That's not just okay, it's a fundamental element of scientific progress -- even though those who fight the consensus are usually wrong.
No one individual has the ability to independently research and verify all of scientific knowledge, so the rational choice is to accept the consensus unless you have invested in becoming sufficiently expert in a field to be able to intelligently challenge that consensus. That doesn't mean you have to challenge the consensus as a whole, either. If you can identify one part of the consensus that isn't correct and you can provide compelling evidence to support your point, that's completely valid, and a valuable contribution which can update and correct the consensus. But note that identifying one error rarely invalidates the entirety of the consensus view; more often it just points out that an adjustment is needed.
What happens when one kills someone like the Uber in Arizona? Is it the driver's fault? The Owners? The Software provider? The Car company? The Sensor company? Absolutely none of this has been decided.
Google said years ago that they would accept liability for damages caused by their self-driving system. Nothing else makes sense; the maker of the system making the decision has to be liable.
I think that's an unacceptably high false positive rate
I've tried the grilling method too.. but in my case it really fared no better. And, frankly, if you can do better, you're in the wrong business.:p You should be recruiting!
The point isn't to grill them, it's to make them actually do something, and watch how they do it.
And, no, I wouldn't want to work as a recruiter. <shudder/>
The problem with the approach is that there is a non-trivial percentage of people who can talk the talk, but can't actually do the job. They're good at understanding the successes of their peers in enough depth to be able to successfully claim them as their own, and even fool a competent interviewer in spite of not being able to do the work themselves.
No. The problem with this approach is that it requires an interviewer that has been in the trenches long enough to have worked with enough of the moochers. Once you've worked with a few, they're easy enough to spot. Unfortunately, competence in interviewers closely tracks competence in the general population.
I've been working in the trenches -- and doing interviews -- for 30 years, and I've worked with plenty of moochers. Maybe you really can spot them without really testing them... but I doubt it.
They can shove the screen space argument up their collective asses until the remove a lot of the extra padding, margins, and whitespace from their apps first.
Who is "they"?
You know the people who build the operating system UI aren't the same people who write apps, right?
So far out of the 8 people I've hired/recommended, only one didn't work out.
I think that's an unacceptably high false positive rate, though it correlates pretty well with what I saw when I used your approach.
The problem with the approach is that there is a non-trivial percentage of people who can talk the talk, but can't actually do the job. They're good at understanding the successes of their peers in enough depth to be able to successfully claim them as their own, and even fool a competent interviewer in spite of not being able to do the work themselves.
Coding interviews are more difficult for everyone involved, but they're much better predictors of success because they require the candidates to actually do something. They're not perfect, of course, because they favor people who can think and solve problems on their feet, which isn't necessarily a required ability in many companies. And they require that the problems to be solved be selected very carefully -- they have to be problems which any competent programmer can solve, that don't require the candidate to have any particular knowledge (unless you have reason to test for that knowledge, in which case I think you're doing it wrong), that don't require the candidate to have any particular brilliant flashes of insight and are something the candidate will not have seen before.
I've tried both your way and the coding interview style, and I get much more information and much better results from the coding interview process. My experience: I did probably a hundred interviews by "just talking" at previous employers, and have done 58 coding interviews since joining my current employer, who trained me on how to do them. (There's an internal web site that provides stats; I haven't tracked it myself.) As for the overall success rate of my employer's process... In my eight years I've worked with probably three hundred other engineers and have encountered exactly one who I thought should not have been hired.
My preferred approach is to use a question that has many different variations, and to start with the easiest variations and then ramp up the difficulty/complexity based the candidate's performance. I only have the candidate write code for one variation, usually the second-hardest one that we talked about, and then ask them how they would go about testing what they implemented. This approach has many advantages.
First, it lets me see how mentally agile they are. Weaker candidates have a hard time adapting their approach as the problem changes, and have a tendency to get locked into early solutions. Better candidates can see how the later variations offer more/different options/tradeoffs and can adapt.
Second, it lets me see how they think through easier variations, to get that strong "process" signal TFA mentions. This gives me good insight into how they approach problem-solving tasks. In some cases it also gives me a clue as to their honesty/integrity, because it's pretty clear when someone has already seen a simple variation of the problem and doesn't admit to it (during my intro I point out that if the candidate has seen the question before, they should let me know).
Third, it gives all but the very weakest candidates some early success, which helps to lower their stress level. There's a limit to how much I can do in that regard, because interviews are inherently stressful situations, but I think it does help... and I think people perform better when they're less stressed.
Fourth, it lets me tune the difficulty of the interview to the candidate's ability level. This is for the candidate's benefit, not to give me any information. Since I'm just one in a slate of interviews, unless I'm the last one the allotted time is fixed and there's no practical way to just cut the interview short (unless they're so bad that I feel I need to end the day entirely to avoid wasting everyone's time; this is very rare). This means that if the candidate is weak and I give them a hard problem, they end up spending the whole hour struggling vainly. This makes for an unpleasant hour for them, an unpleasant hour for me, and it increases their stress level for the next interview. If the candidate finds the first variations of the problem challenging, I just stay at the easy level.
This difficulty-adaptation happens very naturally, because I don't move on to a harder variation until they've solved the previous, easier, one, with whatever hints/tips I need to provide. I watch the clock to decide when to have them change gears from discussing increasingly-harder variations to writing code. On occasion I underestimate the amount of time it will take them to write code and have to tell them to stop before they finish. This happens most often with PhDs, actually, who are often bright and good problem-solvers, but don't have much coding experience -- often even after years in industry. On those occasions, I apologize for not allowing enough time, though I know it's still pretty painful for them not to be able to finish. Whether or not they finish doesn't affect my evaluation much. I get most of what I want to know about their coding skills in the first few minutes of watching them.
Another possibility is that superhero stories are essentially boring, except for the origin stories. It's not acceptable to put the hero in real danger, except temporarily (even when this rule is broken, the audience knows that it just foreshadows a reboot), and since it's become expected that every supervillain that comes along poses a massive threat to at least millions of people, if not the entire universe, superhero stories are mostly an exercise in inventing new ways for villains to be awful and new ways for the hero to save the world.
All really good stories are about character development in the face of moral dilemmas. This is pretty much all an origin story is about. But once the superhero is established, there's just not much room for development any more. You can focus on peripheral characters and their development. Aside from that, about all you can do is feed an adolescent desire to be vicariously powerful (which is fun sometimes, I'll admit, but not as a steady diet).
I've enjoyed a lot of the Marvel movies and series, but I think the reason it's feeling overdone is that... it's overdone. The genre is self-limiting.
Slashdot Mirror
Google accounts online can be protected by 2FA, but your Google device is the weak link, because it has access to all your photos and drive documents without authentication once your device is unlocked.
Be sure to use a short screen lock timeout, set your device to lock when the power button is pressed, and make a habit of always pressing it when you are done using your phone. Basically, maximize the odds that if your device is lost or stolen, it will be in a locked state.
As others have mentioned, finger prints can be faked, passwords can be guessed
Fingerprints can be faked, and I don't have any recommendations as to how to mitigate that risk. You could choose not to use biometric authentication, but in most cases I think that's a bad tradeoff, since the convenience of fingerprint auth makes it practical to lock your phone much more aggressively. So, using fingerprint auth increases your risk against attackers who are willing to go to the effort of lifting prints and making gummi fingers, but increases the odds that lazy attackers will find that your phone is locked against them. I think for most people the tradeoffs fall on the side of aggressive locking and use of fingerprint auth.
Passwords (including PIN and pattern) are harder to guess than you might realize. Android has mandated that password matching happen in secure hardware that enforces guess rate limiting since Nougat. I think the mandated rate limiting is a too permissive, but it's enough that without some clues even guessing a four-digit PIN would take months, if not years. If the attacker is that dedicated and focused, odds are that your phone isn't the path of least resistance.
but none of that matters when the phone is stolen if you are missing the token attached to someone's keychain.
Interesting idea. I haven't heard of any demand for phone login 2FA, but it could be a good idea.
(Note that what follows is me thinking out loud; sorry that it's kind of rambling.)
I'm not sure if a BLE token is the right tool, but it might be. I'll look into it (I'm the lead engineer and manager for some of the relevant bits of Android). I think we'd need backup options in case the token were lost or stolen. Maybe on devices with a biometric authenticator, you could unlock with {password|fingerprint} + token, or if you didn't have your token you could unlock with password + fingerprint, so 2FA that way. Or password + fingerprint + face, if devices with both face auth and fingerprint auth become common. Given the brute force mitigation in place for password auth, I'm pretty comfortable with password auth security on Android (even with fairly weak passwords -- barring shoulder surfing attacks), so maybe the token makes sense as a way to strengthen the inherent weaknesses of consumer-device biometric auth.
If it makes sense to require password + token, then perhaps some other backup option could be implemented. Maybe a set of randomly-generated one-time-use passwords like the backup 2FA passwords for Google account auth. In the event you lost your token, you could pull the printed backups out of your wallet and enter one along with your password. Maybe.
And I wonder if we could even go so far as to use this 2FA token as part of Android Keystore authentication-bound key unlocking, as well as for device unlocking. I could see applications wanting to create keys which can only be used if (a) the user has authenticated themselves in the last X minutes and (b) the token is still in range. This is tricky because the secure hardware used to manage keystore keys probably doesn't have access to the Bluetooth stack... but it might be okay if the token presence requirement were enforced by system software rather than secure hardware. Hmm.
As a more-secure alternative to a BLE token, a smartwatch could be used as the token.
First, just to reiterate... I'm not supporting Verizon in this, in fact I said the opposite. I'm just speculating as to their rationale.
Is supply chain phone theft anymore a problem than say, laptop or TV theft?
Well, it's more of a problem for Verizon, since Verizon doesn't sell laptops or TVs. But, no, not really.
And you can be 100% sure that this locking mechanism will be cracked, just like regular SIM-locking.
This is exactly SIM locking. And it's not so easy to crack in most cases.
Also why 60 days? Why not 60 seconds? What if I want to travel during that 60 days and use a foreign SIM?
I have no idea why they say 60 days.
Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.
What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.
This is a scary argument.
Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.
Actually, you make a good point. Google in this case has far less power than a traditional CA, because each time you set up a WebAuthN authentication with a web site, you generate a new, unique asymmetric key pair and the site you're authenticating to stores the public key. The Google root is used only at that time, by the web site to verify that the key you've provided is stored in some sort of secure hardware -- and only if they care to verify that (in most cases, I can't think they'll even bother.).
Once the key pair has been generated and the public key stored, Google no longer has any role at all in WebAuthN. They can't use their root key to get the web site to accept a different public key as identifying you.
BTW, to be clear, I should say "we", not "they". I'm the lead engineer for and designer of the Android Keystore attestation that is the root of trust for Android WebAuthN. If you have any questions about how keys are generated, managed, revoked, etc., just ask.
Password-less authentication isn't about security -- it's about control and LACK of security. Google wants to hold the keys to the city.
Nope. Google has no access to any of the keys used.
Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.
What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.
Corrected headline - Android is helping to spread pervasive tracking.
You don't know what you're talking about. The FIDO2 approach to online auth uses a different key to authenticate to every we site and is designed to make it impossible to connect a login to one site with a login to another site (unless user-provided data provides a connection between them).
The easy way to get third party countries to block stolen IMEI's would be for the USA/EU and a few others to get together and simply announce they will stop accepting inbound calls from such networks from say six months from now. Watch them scramble to start the blocking.
I think that would violate several international agreements / treaties. Plus it's like killing butterflies with a sledgehammer.
You really think 60 days is going to stop thief? It's not going to make any difference.
It changes what the thief has to do pretty dramatically. The thief can't just take a pallet of phones off a truck and ship them to Africa, he has to get the phones activated on real user accounts for two months first. That basically means he has to steal them from individual users -- and there are additional obstacles created by user passwords, factory reset protections, etc. All very difficult and risky.
I don't think it's the right solution... but it would basically eliminate supply chain phone theft.
It doesn't protect from identity thief at all.
Identity theft is a rather weird thing to complain about.
My guess is that what this is really about is preventing supply chain phone theft. What happens is that phones are stolen while in transit to customers, or out of stores (often by employees), etc., and then shipped to other parts of the world and activated there. There's actually an international clearinghouse for stolen IMEIs, so that theoretically other networks can refuse to allow stolen devices onto their networks. But the destination networks, especially in Africa and Southeast Asia, have little reason to cooperate. Allowing phones to be locked to Verizon's network for 60 days would help with this, because it would ensure that phones stolen before they get activated on a customer account can't be used anywhere (as long as the implementation of the network lock is secure enough).
If my guess is correct, then I kind of understand what they're trying to do... but I think they should just figure out how to secure their supply chain. The inability to network lock was part of the deal when they bought their spectrum so they should deal with it (if you recall; Google was considering becoming a carrier and negotiated a deal with the FCC to buy it, and included a provision in that deal that the spectrum had to be kept open in a couple of ways -- no limitation on tethering and no network locking. Verizon eventually outbid Google and got the 4G spectrum, but the openness requirements attached by Google stayed.)
No. And you forgot to state in your hypothetical that the vehicle in question is dangerous even without the software problems and requires you to be perfectly healthy and agile to get an approximation of a safe ride.
I'm 50 years old and 70 pounds overweight. I find e-scooters to be convenient, fun, cheap and adequately safe urban transportation when I'm traveling. Quicker and less tiring than walking, more convenient, cheaper and more fun than taxi/Uber or renting a car.
I wouldn't use a scooter in bad weather, though. If it's too hot, too cold or too wet, I'll get enclosed transportation. Though I do agree that a scooter widens my tolerance for heat and cold a bit, especially heat.
It wouldn't take more than 2 sentences to include an explanation about ground speed versus air speed. Not even talking about the differences in airspeed at different altitudes and densities, mach, etc. But I guess even that is too much for our technical details-allergic media.
It never occurred to me that anyone would need that explanation. Everyone knows that a tailwind makes you go faster and a headwind makes you go slower. It's utterly obvious that if your engines make you go X mph, and you have a Y mph tailwind, you're going X + Y mph.
Maybe the reporter also thought it was too obvious to waste words on.
Can you find a _single_ reputable physicist or chemist who thinks room temperature superconductors are feasible?
Well, there are these guys. It took 10 seconds of Googling to find that, and there are lots more. If no reputable chemists or physicists believe room temperature superconductors are feasible, there sure are a lot of them wasting their time. The 2016 Nobel Prize in Physics was given to a group of mathematicians and physicists whose research may pave the way towards high-temperature superconductors (as well as a lot more).
Many speculate on the idea
Why do they bother if they all believe it's infeasible? And they clearly do a lot more than just speculate.
but none has demonstrated a practical theory of how to do so.
So your argument is that because no one has achieved it, no one even thinks it's possible? Really?
Given this Navy guy's other patents and the nature of how his invention supposedly works, I'm pretty skeptical that he's done it. I expect that if it's achieved it will be one with some pretty exotic materials and/or complex methods, because if it were easy it would have been done years ago. But assuming it's impossible just because no one has done it is silly.
The main reason I develop on CentOS is that I have the same environment as RHEL.
So that hides the use case you mention from the data.
Not really. Just combine CentOS and RHEL numbers. It's still much smaller than Ubuntu.
2018 RHAT revenue was $2.9 billion. Canonical last year had revenues of $125.97 million. That's a 20x multiple.
The market share follows a similar trend.
The market share does not follow a similar trend, not even if you restrict yourself to the server space, and RH barely even registers in the desktop space.
Red Hat has focused on an easier-to-monetize market segment, that's all.
Art is a response from the artist, often provocative, that channels their consciousness into their creation.
I doubt this. I think most art is much more random than that, and that much of the "channeled consciousness" is post-hoc explanation -- often supplied by the early observers at least as much as by the artist.
this fundamentally boils down to free will and thinking we have some magical divine spark inside us, instead of us just being unimaginably complex meat computers. the jury's still out on that one.
Or both. It's also possible that we are unimaginably complex meat computers with a magical divine spark... but that the same spark exists in elementary particles and the meat computer serves to amplify that weak spark into something visible.
https://en.wikipedia.org/wiki/Free_will_theorem
As to the core question, whether an AI can be an artist, I think there are a couple of problems with Kelly's argument. The first is that he implicitly assumes that only a human can "be responsive to social necessity", which is tantamount to assuming that no AI can ever understand human social context to the same degree that a human can. I think humans don't understand our social context particularly well, so I don't think it's that much of a stretch to think that an AI could do it as well. Especially since subtle errors in understanding the context may just provoke the strongest reactions from viewers of the art.
The second is the common assumption -- which I think is a mistake -- that artists understand / intend the meaning of their own work. They do to some degree, but I think most of the social contextualization that lends meaning to art happens in the eye / mind of the observer not the artist. Especially among avant-garde artists, I think there are a fair number whose real talent is that their nearly-random acts of creation just happen to touch something in the psyches of many people, and especially in the right kind of people, those who are well-positioned to make the artist famous.
Give me a model that will accurately predict the future, I will give you a million dollars.
Define "accurately". And prove to me that you have a million dollars to give me.
No, they don't. They propose different hypotheses. The set of validated (by measurement, observation, proof, experiment, reasoning picked apart) hypotheses is what constitutes a theory.
No theory is ever completely proven. Not only is it always possible to get new observations that will contradict a given theory, it's also possible to posit a different theory that predicts contradictory observations which have not yet been made. This means that consensus is always what defines our current notion of scientific "truth" (which is never absolute, so "truth" is really not a good word). For any given broadly-accepted theory there are often individual scientists who take issue with some element of the theory, or even that propose something quite different. That's not just okay, it's a fundamental element of scientific progress -- even though those who fight the consensus are usually wrong.
No one individual has the ability to independently research and verify all of scientific knowledge, so the rational choice is to accept the consensus unless you have invested in becoming sufficiently expert in a field to be able to intelligently challenge that consensus. That doesn't mean you have to challenge the consensus as a whole, either. If you can identify one part of the consensus that isn't correct and you can provide compelling evidence to support your point, that's completely valid, and a valuable contribution which can update and correct the consensus. But note that identifying one error rarely invalidates the entirety of the consensus view; more often it just points out that an adjustment is needed.
What happens when one kills someone like the Uber in Arizona? Is it the driver's fault? The Owners? The Software provider? The Car company? The Sensor company? Absolutely none of this has been decided.
Google said years ago that they would accept liability for damages caused by their self-driving system. Nothing else makes sense; the maker of the system making the decision has to be liable.
I think that's an unacceptably high false positive rate
I've tried the grilling method too.. but in my case it really fared no better. And, frankly, if you can do better, you're in the wrong business. :p You should be recruiting!
The point isn't to grill them, it's to make them actually do something, and watch how they do it.
And, no, I wouldn't want to work as a recruiter. <shudder/>
How is 7 out of 8 hires/recommendations that *worked out* an "unacceptably high false positive"?
The one that didn't work out is a false positive. One out of eight is too many.
The problem with the approach is that there is a non-trivial percentage of people who can talk the talk, but can't actually do the job. They're good at understanding the successes of their peers in enough depth to be able to successfully claim them as their own, and even fool a competent interviewer in spite of not being able to do the work themselves.
No. The problem with this approach is that it requires an interviewer that has been in the trenches long enough to have worked with enough of the moochers. Once you've worked with a few, they're easy enough to spot. Unfortunately, competence in interviewers closely tracks competence in the general population.
I've been working in the trenches -- and doing interviews -- for 30 years, and I've worked with plenty of moochers. Maybe you really can spot them without really testing them... but I doubt it.
They can shove the screen space argument up their collective asses until the remove a lot of the extra padding, margins, and whitespace from their apps first.
Who is "they"?
You know the people who build the operating system UI aren't the same people who write apps, right?
So far out of the 8 people I've hired/recommended, only one didn't work out.
I think that's an unacceptably high false positive rate, though it correlates pretty well with what I saw when I used your approach.
The problem with the approach is that there is a non-trivial percentage of people who can talk the talk, but can't actually do the job. They're good at understanding the successes of their peers in enough depth to be able to successfully claim them as their own, and even fool a competent interviewer in spite of not being able to do the work themselves.
Coding interviews are more difficult for everyone involved, but they're much better predictors of success because they require the candidates to actually do something. They're not perfect, of course, because they favor people who can think and solve problems on their feet, which isn't necessarily a required ability in many companies. And they require that the problems to be solved be selected very carefully -- they have to be problems which any competent programmer can solve, that don't require the candidate to have any particular knowledge (unless you have reason to test for that knowledge, in which case I think you're doing it wrong), that don't require the candidate to have any particular brilliant flashes of insight and are something the candidate will not have seen before.
I've tried both your way and the coding interview style, and I get much more information and much better results from the coding interview process. My experience: I did probably a hundred interviews by "just talking" at previous employers, and have done 58 coding interviews since joining my current employer, who trained me on how to do them. (There's an internal web site that provides stats; I haven't tracked it myself.) As for the overall success rate of my employer's process... In my eight years I've worked with probably three hundred other engineers and have encountered exactly one who I thought should not have been hired.
My preferred approach is to use a question that has many different variations, and to start with the easiest variations and then ramp up the difficulty/complexity based the candidate's performance. I only have the candidate write code for one variation, usually the second-hardest one that we talked about, and then ask them how they would go about testing what they implemented. This approach has many advantages.
First, it lets me see how mentally agile they are. Weaker candidates have a hard time adapting their approach as the problem changes, and have a tendency to get locked into early solutions. Better candidates can see how the later variations offer more/different options/tradeoffs and can adapt.
Second, it lets me see how they think through easier variations, to get that strong "process" signal TFA mentions. This gives me good insight into how they approach problem-solving tasks. In some cases it also gives me a clue as to their honesty/integrity, because it's pretty clear when someone has already seen a simple variation of the problem and doesn't admit to it (during my intro I point out that if the candidate has seen the question before, they should let me know).
Third, it gives all but the very weakest candidates some early success, which helps to lower their stress level. There's a limit to how much I can do in that regard, because interviews are inherently stressful situations, but I think it does help... and I think people perform better when they're less stressed.
Fourth, it lets me tune the difficulty of the interview to the candidate's ability level. This is for the candidate's benefit, not to give me any information. Since I'm just one in a slate of interviews, unless I'm the last one the allotted time is fixed and there's no practical way to just cut the interview short (unless they're so bad that I feel I need to end the day entirely to avoid wasting everyone's time; this is very rare). This means that if the candidate is weak and I give them a hard problem, they end up spending the whole hour struggling vainly. This makes for an unpleasant hour for them, an unpleasant hour for me, and it increases their stress level for the next interview. If the candidate finds the first variations of the problem challenging, I just stay at the easy level.
This difficulty-adaptation happens very naturally, because I don't move on to a harder variation until they've solved the previous, easier, one, with whatever hints/tips I need to provide. I watch the clock to decide when to have them change gears from discussing increasingly-harder variations to writing code. On occasion I underestimate the amount of time it will take them to write code and have to tell them to stop before they finish. This happens most often with PhDs, actually, who are often bright and good problem-solvers, but don't have much coding experience -- often even after years in industry. On those occasions, I apologize for not allowing enough time, though I know it's still pretty painful for them not to be able to finish. Whether or not they finish doesn't affect my evaluation much. I get most of what I want to know about their coding skills in the first few minutes of watching them.
Another possibility is that superhero stories are essentially boring, except for the origin stories. It's not acceptable to put the hero in real danger, except temporarily (even when this rule is broken, the audience knows that it just foreshadows a reboot), and since it's become expected that every supervillain that comes along poses a massive threat to at least millions of people, if not the entire universe, superhero stories are mostly an exercise in inventing new ways for villains to be awful and new ways for the hero to save the world.
All really good stories are about character development in the face of moral dilemmas. This is pretty much all an origin story is about. But once the superhero is established, there's just not much room for development any more. You can focus on peripheral characters and their development. Aside from that, about all you can do is feed an adolescent desire to be vicariously powerful (which is fun sometimes, I'll admit, but not as a steady diet).
I've enjoyed a lot of the Marvel movies and series, but I think the reason it's feeling overdone is that... it's overdone. The genre is self-limiting.