But that Linux, or Debian, doesn't have a core shared library somewhere that is able to read lines is, quite frankly, astonishing to me.
The question is whether there was such a library when apt was written, in the early 90s. And whether it was guaranteed to be present on a base install, or whether it was something that apt was going to be installing. If not, then apt couldn't use a shared library version so it would have to statically link it, which may have argued for implementing something very simple instead.
Remember that when apt was written installation was generally done from floppy disks so a little inefficiency in the parsing code wouldn't have been noticed.
Just call it what is was: Legalized Theft, backed by the power of law.
Is, not was. The headline is wrong. They didn't shut it down, they just decided not to share the proceeds with local and state law enforcement. That probably will reduce the amount of civil forfeiture that happens since those agencies now have less incentive to do it (except as allowed by the -- generally less lucrative -- stat civil asset forfeiture laws), but it's not going away.
SpaceX has launched a previously launched vertically self-landing rocket exactly zero times, so statistics is not going to provide anything in the probabilities department. "Assuming they maintain this success rate" is a rather big assumption.
Did you read the thread? The claim was that there was a 50% chance of complete loss of the cargo. But SpaceX has launched 20 Falcon 9s, and only lost one. The fact that this is only the fourth time they attempted to land the first stage, and the first time they succeeded, is completely orthogonal to the question of cargo survival, because that has nothing to do with the landability of the first stage.
1. Security key (any FIDO U2F-compliant device will work). This is a small device that plugs into a USB port. Some of them also have NFC capability so you can use them on your phone by tapping the key against the back of your phone. If you have multiple Google accounts you can use the same security key for all of them.
2. Google Authenticator app, or compatible (it's an open standard). The app also supports multiple accounts, and does both time-based and counter-based codes.
3. SMS.
4. Voice call.
5. Backup codes. You get these from the Google account web site, print them out and keep them in a safe place. Great when traveling, in case your phone gets lost or broken. I keep some in my wallet and some in my suitcase.
I have all of the above set up, including multiple SMS/voice phone numbers. I'm never getting locked out of my account.
Here you got one right, every code has a 60 second lifespan. (:
Google also provides OTPs that are not time-limited. They're called backup codes; you get them from the Google account web site, print them out and keep them in a safe place. It's good to keep a few in your wallet when traveling, in case your phone is lost or broken.
Just because it's relatively cheap to use Space X, if I have a 50-50 ( better or worse) chance that my $100 million satellite that took several years to design and build is going to get blown up, I'll pass.
SpaceX has launched 20 times, with one failure. So, that's a 5% chance of loss, not 50%, assuming they maintain this success rate.
They're also ineffective. Corbett is already suing to block them (Corbett v TSA, No. 15-10757-A 11th Cir). (Full case docs are in my gdrive archive if you're interested. See link on s.ai sidebar -> case law -> tsa / dhs -> corbett -> corbett v tsa no 15-10757-a.)
It's ongoing, in initial stages.
They can be effective, c.f. Israeli airport security. However, they're manpower-intensive, time-consuming (when flying out of Ben Gurion it's advisable to arrive at 3-4 hours before your flight. If you are an Arab, make it 5+ hours) and very intrusive and invasive. We really, really don't want effective passenger interviews.
I'm sorry...but not everything needs to revolve around the 'phone'.
My phone is stolen/broken/lost..and now I can't use my laptop to get into my email?
"You won’t need your password to sign in, but you can always use it if you want to"
And after a while of not using that password...you've completely forgotten it.
So make sure that you have backup password reset options configured, like SMS to the phone of a trusted friend or two, and some one-time codes printed out and stored in a safe place.
Also, it wouldn't surprise me if the new feature actually does require you to use your password once in a while, specifically to ensure you don't forget it. Android does that for phones with fingerprint authentication, so you don't forget it.
If somebody has access to your phone, they have access to your email.
Maybe in Google's fantasy world, but certainly not in the world I now live in, using my actual phone, they don't! Having any possible connection between my phone and my email would be a bloody stupid thing to do, given the "security" of most phones.
I guess Freedom Bug should have qualified it with "For values of 'you' that include 99% of smartphone users."
What is surprising to me is that we haven't heard more from the likes of Freightliner.
Mercedes has always been risk-averse. They're not afraid to cram a lot of fancy technology into their S-Class cars, but most of it is well-proven long before they shove it in there anyway. Meanwhile, they mostly do things the old way and let other companies take the risks. Freightliner has only announced plans for driver assistance so far, and no full autonomy.
Well, whichever of the truck manufacturers gets there first -- Mack, Peterbilt, Kenworth, Volvo, etc. -- is going to do a great business. Long haul trucking is just begging for automation.
As I recall, Google has been saying for while that they'd have something ready by 2017. On the one hand it seems like it should be surprising if Tesla manages to make it to market at the same time, since they got a much later start. On the other hand, it probably shouldn't surprise us if multiple companies get there at about the same time, since it's less about the cleverness in building the system than it is about having all of the fundamental technological pieces to do it. In particular, I think deep learning neural networks are the core technology that will make effective fully-autonomous cars feasible (plus the sensors, but those have been available for years), and to a large degree the whole world got access to that theory and practice at about the same time.
What is surprising to me is that we haven't heard more from the likes of Freightliner. IMO, that is the first really major market for self-driving vehicles, and those don't even need to be fully autonomous. If tractor-trailer rigs can just drive themselves on the freeway, freight companies can immediately get rid of 90% of their drivers and massively reduce their costs, by having a human drive the truck to the freeway then hop out and let it travel to the destination city, where another human will drive it through town to its destination. Plus, given the price of a semi tractor, adding $50K or even $100K for an automation suite is a relatively small incremental cost, while it's a rather large chunk of change for a passenger vehicle.
(Disclaimer: I work for Google, but not on self-driving vehicles and I don't know any more about the status of Google's system than what is in the public press.)
Na. Self driving cars can be run with open source software and a Raspberry Pi. Just need a few years for things to catch up. There's zero money to be made here. Apple don't want none of this.
Software is in fact inherently LESS reliable than hardware, because hardware generally fails gradually, in ways that can be predicted and checked ahead of time for (like checking for cracks on a belt). Software though, either works or generally fails spectacularly - because of two factors - one is that storage wears out or gets corrupted sometimes, the other is that sensors fail and with bad input comes our friend GIGO.
Having binary failure modes (either works or fails spectacularly) makes it more reliable, because (assuming comparable complexity), hardware has more wear modes. The only reason you think those can be predicted and checked ahead of time is because you happen to know the common ones. If worn out or corrupted storage is sufficiently common then it is even easier to check for... in fact the software can (and often does) do it automatically in a power-on self-test.
The only case where that breaks down is when the hardware running the software fails. That could be addressed with redundancy but generally isn't in automotive applications (unlike aerospace applications).
Regarding sensors and GIGO, those issues also plague any purely hardware implementations that rely on sensors of some sort. It doesn't matter whether the sensor response is analog and mechanical or computerized and digital. Further, it's much easier for software to detect and work around garbage. In fact, this is exactly what a lot of automotive software does. For example, if your O2 sensor goes out and starts reporting garbage, the software recognizes the failure, attempts to work around it to keep things running somewhat well and flicks on the "check engine" light. If you then connect to the OBDII interface, it'll give you a failure code telling you that the O2 sensor is bad.
Software is inherently less reliable because with a complex enough system you literally cannot predict what an infinite combination of partially or fully failing sensors and electrical connections will mean with software behavior... with mechanical systems the failure also generally is fairly isolated, while with software failure is much mire likely to be broad in scope.
This just another way to state the point that I made, that software allows us to reach for much greater complexity than mechanical hardware does. Mechanical solutions tend to be simpler because complex ones are dramatically more failure prone and harder to test and debug than software solutions, as well as being harder to build in the first place. So it's not software that is unreliable, it's complexity. But complexity can be managed and minimized in software, as long as the effort is made to do so. And, actually, automotive software in reliability-critical components is pretty good at this.
Software is inherently more reliable than mechanical hardware, at comparable levels of complexity. It doesn't wear out, has fewer failure modes which are easier to understand, can identify and adapt to hardware failures in ways that mechanical solutions cannot and can more directly and accurately report identified failures. Further, those characteristics mean that software can be more reliable than mechanical hardware even when the software is somewhat more complex.
Yes, there are abandoned claims like phlogiston and phrenology, but I question if you could ever call any of them "scientific".
Why not? They (well, phlogiston, at least) were reasonable hypotheses based on observations, with considerable explanatory power that produced lots of testable predictions. That's exactly what you want in a scientific hypothesis. The fact that phlogiston theory was wrong doesn't mean it wasn't scientific.
The worst fate seems to be what happened to Newtonian mechanics, which were subsumed in Relativity and ended up becoming a still useful set of calculations for non-relativistic velocities, more than adequate to land probes on Mars or put humans on the Moon.
But not to operate a Global Positioning System. Newton's theories are wrong. In terms of calculations the degree of wrongness is slight in most circumstances, but in terms of explanations of what's going on underneath the calculations Newton was completely wrong. Gravitational "force" does not, in fact, exist!
Those of us that work with software pale at the thought of myriad car components being "software defined".
I think I'll be hanging on to my mostly hardware defined car for quite a few years as this all plays out...
Unless your car is pretty old, it's already heavily driven by software. Electronic Fuel Injection? The venerable timing chain/belt has been replaced by software, and it's software that is pretty smart about when to inject fuel and fire the spark plugs, constantly varying the timing by small amounts as engine demands change, and based on real-time reports from various sensors. Anti-lock brakes? Software. There's probably software embedded in your transmission. I drive an electric car, and there's very little of it that isn't software-controlled.
All of that software is actually a big part of why vehicles today are safer, more reliable and more fuel-efficient than they were in decades past.
But I also don't like suffering the death of a thousand cuts with small things going inexplicably wrong in a car all the time either.
Software is inherently more reliable than hardware, since it doesn't wear out. What makes so much software bad is the fact that it's feasible to build stuff that is several orders of magnitude more complex than anything we'd attempt with hardware. Complexity is the enemy of reliability. On the other hand complexity enables us to do more, and better. So the key is to manage the complexity appropriately; minimizing it where possible and thoroughly validating it where the complexity is actually necessary. This is totally possible. The aerospace industry uses a tremendous amount of software, and makes it highly reliable.
The automotive industry isn't very good at software, but in practice I think that's less of a problem that it appears, because the software that actually runs the parts of your car that are really important isn't very complex at all compared to most software systems, and applying standard hardware testing methodologies to the combined software and hardware works pretty well to flush out the problems. So, while there are problems, they tend to be relatively minor and obscure.
In other areas, like entertainment systems, automotive software tends to suck. Partly that's because it doesn't get the same level of testing, but mostly it's because testing isn't good at identifying user experience problems.
Security is also not very testable, and is another area where automotive software tends to be awful. Thus far that hasn't been a problem in practice. It's the one area that really concerns me.
What you ignored was that I never claimed 100% rationality. I just described what humans in large groups actually do, based on easily-observed, thoroughly-measured and extensively-documented real-world statistics.
Never, NEVER forget the impact that the instincts have on the general behavior of the population. Everyone thinks that human beings are rational but in reality people are an entity 50% rationality 50% instinct, with variations in this proportion from one individual to another.
And yet, what is actually happening in real human populations follows the patterns I described, not the ones that develop in lab mice.
Low population growth typically indicates an educated populace, low infant mortality, and a high cost to rear children because of a high cost of living caused by a luxury economy.
In mice, and other animals who don't have either the means nor the motive to rationally plan their families.
Humans have rather different dynamics, and the GP's statement is correct. It's very easy to show that as infant mortality declines and wealth rises, parents choose to have fewer children and invest much more in them. This is why the first world is already at negative population growth. In some parts of northern Europe the population decline is becoming a problem, to the degree that, for example, the Danish government has been running an advertising campaign to encourage people to have children.
The population of the US would be shrinking, but immigration is keeping it growing by about 2M people per year. There are only about 1M immigrants per year, but first-generation immigrants tend to have larger families which props up the birth rate. However, the net growth rate is declining and assuming current trends remain unchanged the US will hit zero growth in about 30 years and then population will begin to decrease. The assumption that current trends continue is a pretty big one though, given the massive changes we have coming in that time frame, as automation increases dramatically. Climate change may have some effect as well.
Slashdot Mirror
But that Linux, or Debian, doesn't have a core shared library somewhere that is able to read lines is, quite frankly, astonishing to me.
The question is whether there was such a library when apt was written, in the early 90s. And whether it was guaranteed to be present on a base install, or whether it was something that apt was going to be installing. If not, then apt couldn't use a shared library version so it would have to statically link it, which may have argued for implementing something very simple instead.
Remember that when apt was written installation was generally done from floppy disks so a little inefficiency in the parsing code wouldn't have been noticed.
Just call it what is was: Legalized Theft, backed by the power of law.
Is, not was. The headline is wrong. They didn't shut it down, they just decided not to share the proceeds with local and state law enforcement. That probably will reduce the amount of civil forfeiture that happens since those agencies now have less incentive to do it (except as allowed by the -- generally less lucrative -- stat civil asset forfeiture laws), but it's not going away.
SpaceX has launched a previously launched vertically self-landing rocket exactly zero times, so statistics is not going to provide anything in the probabilities department. "Assuming they maintain this success rate" is a rather big assumption.
Did you read the thread? The claim was that there was a 50% chance of complete loss of the cargo. But SpaceX has launched 20 Falcon 9s, and only lost one. The fact that this is only the fourth time they attempted to land the first stage, and the first time they succeeded, is completely orthogonal to the question of cargo survival, because that has nothing to do with the landability of the first stage.
Wrong. That is 5% failure over time. Each individual launch is still 50/50
The probability that you got a good grade in your probability & statistics class is very low.
fyi, google two factor authentication uses sms...
Google two-factor uses any and all of:
1. Security key (any FIDO U2F-compliant device will work). This is a small device that plugs into a USB port. Some of them also have NFC capability so you can use them on your phone by tapping the key against the back of your phone. If you have multiple Google accounts you can use the same security key for all of them.
2. Google Authenticator app, or compatible (it's an open standard). The app also supports multiple accounts, and does both time-based and counter-based codes.
3. SMS.
4. Voice call.
5. Backup codes. You get these from the Google account web site, print them out and keep them in a safe place. Great when traveling, in case your phone gets lost or broken. I keep some in my wallet and some in my suitcase.
I have all of the above set up, including multiple SMS/voice phone numbers. I'm never getting locked out of my account.
Here you got one right, every code has a 60 second lifespan. (:
Google also provides OTPs that are not time-limited. They're called backup codes; you get them from the Google account web site, print them out and keep them in a safe place. It's good to keep a few in your wallet when traveling, in case your phone is lost or broken.
Just because it's relatively cheap to use Space X, if I have a 50-50 ( better or worse) chance that my $100 million satellite that took several years to design and build is going to get blown up, I'll pass.
SpaceX has launched 20 times, with one failure. So, that's a 5% chance of loss, not 50%, assuming they maintain this success rate.
They're also ineffective. Corbett is already suing to block them (Corbett v TSA, No. 15-10757-A 11th Cir). (Full case docs are in my gdrive archive if you're interested. See link on s.ai sidebar -> case law -> tsa / dhs -> corbett -> corbett v tsa no 15-10757-a.)
It's ongoing, in initial stages.
They can be effective, c.f. Israeli airport security. However, they're manpower-intensive, time-consuming (when flying out of Ben Gurion it's advisable to arrive at 3-4 hours before your flight. If you are an Arab, make it 5+ hours) and very intrusive and invasive. We really, really don't want effective passenger interviews.
Even though from a tracking perspective Google's ads are probably the worst of the lot, if only because of their pervasiveness.
So use the opt-out Google provides.
Cheaper, more effective methods (trained sniffer dogs, passenger interviews, locks on the cockpit door) are already well-proven
I agree with the others, but passenger interviews are more expensive, not cheaper.
a phone whose OS contains sourcecode partly written on a computer running Ubuntu.
FYI, most Android source code is written on computers running Goobuntu, which is a Google-internal customized version of Ubuntu.
Baking in an adblocker will certainly raise eyebrows in Google and other big advertising syndicates.
Probably not so much at Google since Google's ads comply with the ADP+ acceptable ads policy and are not blocked.
I'm sorry...but not everything needs to revolve around the 'phone'. My phone is stolen/broken/lost..and now I can't use my laptop to get into my email? "You won’t need your password to sign in, but you can always use it if you want to" And after a while of not using that password...you've completely forgotten it.
So make sure that you have backup password reset options configured, like SMS to the phone of a trusted friend or two, and some one-time codes printed out and stored in a safe place.
Also, it wouldn't surprise me if the new feature actually does require you to use your password once in a while, specifically to ensure you don't forget it. Android does that for phones with fingerprint authentication, so you don't forget it.
If somebody has access to your phone, they have access to your email.
Maybe in Google's fantasy world, but certainly not in the world I now live in, using my actual phone, they don't! Having any possible connection between my phone and my email would be a bloody stupid thing to do, given the "security" of most phones.
I guess Freedom Bug should have qualified it with "For values of 'you' that include 99% of smartphone users."
Model E or whatever he called it, an electric car with some 200+ mile range under 40K. When did he say it would ship?
Model 3. Late 2017. I really doubt it will be self-driving, though. I'm sure they'll start with the high end for the new features.
What is surprising to me is that we haven't heard more from the likes of Freightliner.
Mercedes has always been risk-averse. They're not afraid to cram a lot of fancy technology into their S-Class cars, but most of it is well-proven long before they shove it in there anyway. Meanwhile, they mostly do things the old way and let other companies take the risks. Freightliner has only announced plans for driver assistance so far, and no full autonomy.
Well, whichever of the truck manufacturers gets there first -- Mack, Peterbilt, Kenworth, Volvo, etc. -- is going to do a great business. Long haul trucking is just begging for automation.
As I recall, Google has been saying for while that they'd have something ready by 2017. On the one hand it seems like it should be surprising if Tesla manages to make it to market at the same time, since they got a much later start. On the other hand, it probably shouldn't surprise us if multiple companies get there at about the same time, since it's less about the cleverness in building the system than it is about having all of the fundamental technological pieces to do it. In particular, I think deep learning neural networks are the core technology that will make effective fully-autonomous cars feasible (plus the sensors, but those have been available for years), and to a large degree the whole world got access to that theory and practice at about the same time.
What is surprising to me is that we haven't heard more from the likes of Freightliner. IMO, that is the first really major market for self-driving vehicles, and those don't even need to be fully autonomous. If tractor-trailer rigs can just drive themselves on the freeway, freight companies can immediately get rid of 90% of their drivers and massively reduce their costs, by having a human drive the truck to the freeway then hop out and let it travel to the destination city, where another human will drive it through town to its destination. Plus, given the price of a semi tractor, adding $50K or even $100K for an automation suite is a relatively small incremental cost, while it's a rather large chunk of change for a passenger vehicle.
(Disclaimer: I work for Google, but not on self-driving vehicles and I don't know any more about the status of Google's system than what is in the public press.)
Na. Self driving cars can be run with open source software and a Raspberry Pi. Just need a few years for things to catch up. There's zero money to be made here. Apple don't want none of this.
Apple is already working on it.
Software is in fact inherently LESS reliable than hardware, because hardware generally fails gradually, in ways that can be predicted and checked ahead of time for (like checking for cracks on a belt). Software though, either works or generally fails spectacularly - because of two factors - one is that storage wears out or gets corrupted sometimes, the other is that sensors fail and with bad input comes our friend GIGO.
Having binary failure modes (either works or fails spectacularly) makes it more reliable, because (assuming comparable complexity), hardware has more wear modes. The only reason you think those can be predicted and checked ahead of time is because you happen to know the common ones. If worn out or corrupted storage is sufficiently common then it is even easier to check for... in fact the software can (and often does) do it automatically in a power-on self-test.
The only case where that breaks down is when the hardware running the software fails. That could be addressed with redundancy but generally isn't in automotive applications (unlike aerospace applications).
Regarding sensors and GIGO, those issues also plague any purely hardware implementations that rely on sensors of some sort. It doesn't matter whether the sensor response is analog and mechanical or computerized and digital. Further, it's much easier for software to detect and work around garbage. In fact, this is exactly what a lot of automotive software does. For example, if your O2 sensor goes out and starts reporting garbage, the software recognizes the failure, attempts to work around it to keep things running somewhat well and flicks on the "check engine" light. If you then connect to the OBDII interface, it'll give you a failure code telling you that the O2 sensor is bad.
Software is inherently less reliable because with a complex enough system you literally cannot predict what an infinite combination of partially or fully failing sensors and electrical connections will mean with software behavior... with mechanical systems the failure also generally is fairly isolated, while with software failure is much mire likely to be broad in scope.
This just another way to state the point that I made, that software allows us to reach for much greater complexity than mechanical hardware does. Mechanical solutions tend to be simpler because complex ones are dramatically more failure prone and harder to test and debug than software solutions, as well as being harder to build in the first place. So it's not software that is unreliable, it's complexity. But complexity can be managed and minimized in software, as long as the effort is made to do so. And, actually, automotive software in reliability-critical components is pretty good at this.
Software is inherently more reliable than mechanical hardware, at comparable levels of complexity. It doesn't wear out, has fewer failure modes which are easier to understand, can identify and adapt to hardware failures in ways that mechanical solutions cannot and can more directly and accurately report identified failures. Further, those characteristics mean that software can be more reliable than mechanical hardware even when the software is somewhat more complex.
China has a thieving industry of original design manufacturers (ODMs)
Fixed that for you.
If they were only thieving, there would be no need for EEs there, and increasing need here.
Yes, there are abandoned claims like phlogiston and phrenology, but I question if you could ever call any of them "scientific".
Why not? They (well, phlogiston, at least) were reasonable hypotheses based on observations, with considerable explanatory power that produced lots of testable predictions. That's exactly what you want in a scientific hypothesis. The fact that phlogiston theory was wrong doesn't mean it wasn't scientific.
The worst fate seems to be what happened to Newtonian mechanics, which were subsumed in Relativity and ended up becoming a still useful set of calculations for non-relativistic velocities, more than adequate to land probes on Mars or put humans on the Moon.
But not to operate a Global Positioning System. Newton's theories are wrong. In terms of calculations the degree of wrongness is slight in most circumstances, but in terms of explanations of what's going on underneath the calculations Newton was completely wrong. Gravitational "force" does not, in fact, exist!
Those of us that work with software pale at the thought of myriad car components being "software defined".
I think I'll be hanging on to my mostly hardware defined car for quite a few years as this all plays out...
Unless your car is pretty old, it's already heavily driven by software. Electronic Fuel Injection? The venerable timing chain/belt has been replaced by software, and it's software that is pretty smart about when to inject fuel and fire the spark plugs, constantly varying the timing by small amounts as engine demands change, and based on real-time reports from various sensors. Anti-lock brakes? Software. There's probably software embedded in your transmission. I drive an electric car, and there's very little of it that isn't software-controlled.
All of that software is actually a big part of why vehicles today are safer, more reliable and more fuel-efficient than they were in decades past.
But I also don't like suffering the death of a thousand cuts with small things going inexplicably wrong in a car all the time either.
Software is inherently more reliable than hardware, since it doesn't wear out. What makes so much software bad is the fact that it's feasible to build stuff that is several orders of magnitude more complex than anything we'd attempt with hardware. Complexity is the enemy of reliability. On the other hand complexity enables us to do more, and better. So the key is to manage the complexity appropriately; minimizing it where possible and thoroughly validating it where the complexity is actually necessary. This is totally possible. The aerospace industry uses a tremendous amount of software, and makes it highly reliable.
The automotive industry isn't very good at software, but in practice I think that's less of a problem that it appears, because the software that actually runs the parts of your car that are really important isn't very complex at all compared to most software systems, and applying standard hardware testing methodologies to the combined software and hardware works pretty well to flush out the problems. So, while there are problems, they tend to be relatively minor and obscure.
In other areas, like entertainment systems, automotive software tends to suck. Partly that's because it doesn't get the same level of testing, but mostly it's because testing isn't good at identifying user experience problems.
Security is also not very testable, and is another area where automotive software tends to be awful. Thus far that hasn't been a problem in practice. It's the one area that really concerns me.
What you ignored was that I never claimed 100% rationality. I just described what humans in large groups actually do, based on easily-observed, thoroughly-measured and extensively-documented real-world statistics.
Never, NEVER forget the impact that the instincts have on the general behavior of the population. Everyone thinks that human beings are rational but in reality people are an entity 50% rationality 50% instinct, with variations in this proportion from one individual to another.
And yet, what is actually happening in real human populations follows the patterns I described, not the ones that develop in lab mice.
Low population growth typically indicates an educated populace, low infant mortality, and a high cost to rear children because of a high cost of living caused by a luxury economy.
More like population density without resource constraints.
In mice, and other animals who don't have either the means nor the motive to rationally plan their families.
Humans have rather different dynamics, and the GP's statement is correct. It's very easy to show that as infant mortality declines and wealth rises, parents choose to have fewer children and invest much more in them. This is why the first world is already at negative population growth. In some parts of northern Europe the population decline is becoming a problem, to the degree that, for example, the Danish government has been running an advertising campaign to encourage people to have children.
The population of the US would be shrinking, but immigration is keeping it growing by about 2M people per year. There are only about 1M immigrants per year, but first-generation immigrants tend to have larger families which props up the birth rate. However, the net growth rate is declining and assuming current trends remain unchanged the US will hit zero growth in about 30 years and then population will begin to decrease. The assumption that current trends continue is a pretty big one though, given the massive changes we have coming in that time frame, as automation increases dramatically. Climate change may have some effect as well.