And roughly ten thousand times as much agricultural land is lost in any given year to new office parks, golf courses, condos, and discount retail stores.
Spoiler: the desert is a great place to build sprawling metro areas (Las Vegas, Phoenix, Dubai, Salt Lake City...). The Sahara (just to name one) is really fucking huge, and it's unlikely to either flood or be covered in glaciers anytime within the next million years.
So dig Florida-style finger canals to create new, valuable waterfront property to sell to foreigners for vacation homes, and use the revenue to pay for raising the rest of the main island for Kiribati's own residents.
Permeable ground just means you can't rely on levees or dikes to keep land that's below sea level dry. Raise the terrain itself (via dredged fill dirt) above sea level, and the problem is solved. The city of Chicago literally raised most of its land & buildings (and reversed the direction of the Chicago river) more than a hundred years ago. See: https://en.wikipedia.org/wiki/...
Guaranteed: if Kiribati were formally abandoned by its inhabitants and evacuated in some grand public gesture of eco-catastrophe, someone else (China, Russia, militant libertarians, etc) would show up, occupy the islands one by one, and declare ownership & sovereignty within a matter of days.
> The Russian won't be able to heat his home when the economy collapses due to climate change
Er.... out of all the countries on Earth, with the possible exception of Canada, I struggle to think of a country that's more likely to be a net beneficiary of climate change than Russia.
Obligatory joke: In Soviet Russia, climate changes YOU...
In theory, FTDI's USB-UART chips can bitbang... but AFAIK, no windows, Linux, or osx drivers have any kind of API for using it on a computer. You have to program the bare metal directly using a microcontroller. The catch is that due to the way USB modes work, the max usable rate is about 1 mbps... and that assumes a lockstep transfer of data AT 1mbps with fairly precise timing using isochronous mode. If you want to sample the pins at arbitrary rates, the max usable rate is about 1/64th of that (using "control" mode)... maybe less.
In theory, a FTDI chip capable of native USB3.0 with interrupts tied to an external clock line could probably bitbang SCSI-1, but AFAIK, they haven't made such a chip yet.
Long before they were creating special models for Black Friday, retailers like CompUSA and Circuit City were buying up laptops with known design flaws (like a model made with hard drives whose fucked-up firmware seemingly worked fine with FAT32, but would slowly mangle NTFS or EXT2... their excuse was that they never said it would work with anything besides the OS it shipped with (Windows 98, if I recall). Goddamn, I spent literally 3 weeks trying to figure out why Windows 2000 Pro would self-destruct within days every time I installed it on my Dad's new Black Friday laptop. When I found out the real reason, I was beyond livid. And it's a major reason why I now won't touch a Black Friday Sale laptop with a 10-foot dirty tetanus-infested pole, and will never trust the quality of HP's consumer-grade laptops again. I would have been totally fine with their offering the laptop at discounted prices IF they'd boldly disclosed on the box that the laptop was made with a hard drive that had defective firmware that would corrupt NTFS and EXT2... but they didn't. The mother fuckers just hoped that most people wouldn't notice.
I'm pretty sure that most of the "40 million" are sharing a SSN with somebody who died *years* ago, and that the number of people like the two women cited as an example is much, MUCH smaller.
I mean, for ${deity.name}'s sake, there are only ~300 million *AMERICANS*. If one in 8 Americans had SSN collisions with another living person, I can *guarantee* it wouldn't have taken until now to be newsworthy.
That said, the gov't really needs to add at least a digit or two. Just adding one digit & making every existing SSN end with "0" until 2025 (to allow a graceful transition where existing 9-digit numbers would have an easily-derived 10-digit value) would give them enough unique numbers to go a few centuries without ever reusing a number.
Is there any free rsync SERVER capable of running under 64-bit Windows 7 Pro and working with any known Android rsync client over wifi (to an ext2-formatted hard drive mounted using ext2fsd)?
If you efficiently collected 100% of the water dripping from a typical 3-5 ton South Florida central AC unit on a 90-degree day with 99% relative humidity, you MIGHT end up with enough water to flush a toilet once or twice. Maybe 5 gallons, if you were lucky.
As others have noted, Android's biggest performance problems come down to architectural compromises made *years* ago so Android could run (walk?) on 200Mhz devices with 480x320 displays and almost no RAM circa 2009. Just about everything Android does is PIO-based... and the closed nature of Qualcomm's chipsets means end users are still running on an ever-accelerating treadmill with every new device & version of Android just to have a working camera & GPS under the new (and 100% incompatible with binary.ko drivers) kernel every new version of Android inevitably demands.
Correction: Qualcomm has a near-monopoly on SoCs capable of doing LTE on American mobile networks in all licensed bands without additional chips. If you want a single-chip 4+ core Android device that works with 100% support for all relevant bands & data modes on Verizon, Sprint, or even AT&T, you basically have one viable choice: Qualcomm.
Renesas had a competitive alternative chipset ~2 years ago, but the new owners seem to have no real interest in trying to compete with Qualcomm in the US anymore for top-shelf flagship-class device5 and AFAIK are only now interested in the throwaway low-end.
SHA-1 hasn't been "defeated" -- at most, an attacker able to muster substantial computer resources *might* be able to discover a random binary file of random length that shares the same SHA-1 hash as something else.
In other words, there might be some denial-of-service potential if an attacker were able to forge the signature for an update file & trick a remote computer into replacing good files with nonworking ones, but that's pretty much *it* for the immediate future.
Should a new app use SHA-2? Of course. It's no harder to use, and bulletproof at this point. But there's no great urgency to replace SHA-1 in existing code at this point.
Actually, there's a well-established precedent for regulating private venues as de-facto public squares. See Pruneyard Shopping Center v. Robins [ https://en.wikipedia.org/wiki/... ]
And what's more valuable to an intelligence agency... someone with a neurotically-groomed token profile based on their "real" name, or someone with an extensive profile under a technically-fake name (a name that's practically a de-facto GUID because they use it in other parts of their daily lives)?
The ultimate nightmare scenario for the National Weather Service: a confirmed rain-wrapped EF0 tornado that touches down in Miami or Fort Lauderdale at 4pm & is clearly heading towards I-95. If they say nothing, the tornado is unlikely to kill anyone, because everyone will be driving slowly due to the torrential rain anyway. On the other hand, if they send out a warning that a tornado is about to cross I-95, some idiot is almost **guaranteed** to abandon his car, attempt to cross 4-6 lanes of traffic, and get run over (because it's still bumper-to-bumper 30-40mph traffic, but near-zero visibility). And probably trigger a 7-car pile-up in the process.
And if it's "automatic", almost by definition it's always online & thus vulnerable to a potentially WORSE (insofar as data recovery is concerned) mode of failure... encryption by ransomware.
Seriously. Name one... ONE... NAS or online backup solution that allows continuous adhoc writing, but acts like a virtual WORM filesystem and merely marks obsolete files as 'deleted' without actually deleting them, so that any attempt by ransomware to encrypt the files on the backup drive would simply fill up the drive until the ransomware crashed (and quite possibly provide an early warning of what it was up to).
In some ways, it feels like we've gone backwards over the past 20 years. Capacities have increased exponentially, but new hard drives seem to drop like flies compared to drives from 10-20 years ago. And often, they fail in creative ways that RAID (1, 5, 10, or whatever) can't save you from (golden example: OCZ's second-generation SSDs with Sandforce controllers that simultaneously omitted the supercapacitor needed to make sure the drive never lost power during writes (to save about a dollar per drive) AND disabled the multi-step safety measures Sandforce built into the default firmware (because it made the drives slow).
or something to that effect. I don't remember whether it was just a temporary work-around to a bug in the current version of GCC, or something more fundamental... but it totally turned me off. I went back to assembly. It was easier, and made more sense.
The catch is, not all devices (especially devices more than a few years old) ARE "sanely designed". I remember quite well that the original Palm III had fairly demanding battery requirements... it was good for about a month with Duracell or Energizer alkalines, but only lasted 2-3 weeks with store-brand alkaline cells, and only lasted a few DAYS with NiMH cells. Ditto for my piece-of-shit Minolta d'Image DSLR, which was good for about 10 photos on brand new alkaline batteries before shutdown.
That said, the marketers behind this aren't being entirely honest... they're presenting the best-possible and most extreme edge case as the universal norm. It will make a HUGE difference for some (badly-designed/cost-cut) devices, and make no positive difference for well-designed devices. Regardless, it'll be useful, because shit devices vastly outnumber well-designed ones.
Fiber of any kind is a waste of money unless you already know what you're going to terminate it with at both ends. Fiber might be "future-proof" in the sense that someone, someday, will make converter boxes to let you use older fiber for new purposes... but I can guarantee that any such conversion box will end up costing WAY more than you'd have likely spent just buying a spool of new fiber and pulling it through a conduit. That's why conduit is so great. You don't HAVE to try and guess an unpredictable future, and spend eternity putting band-aids on your mistakes from 20 years ago. Put in conduit, and you can pull whatever you need, when you eventually need it.
Conduit. The future might be wireless, but the wireless you'll have to use won't be able to penetrate a window, much less a wall. Conduit will allow you to pull cheap cat5e today, and replace it with fiber 10-20 years from now when you finally NEED it.
Run conduit to every room where you think you might someday want to have a network connection, or need to put a line-of-sight access point. Don't forget the bathrooms, garage, basement, and snack bar in the kitchen.
From at least one box in each room where you're terminating the low-voltage conduit, run another conduit up to somewhere on the ceiling about a foot or two from the wall. You can omit the boxes and just leave the conduit there (photographed and documented for future reference), but they'll make your life INFINITELY easier if you someday need to put an access point on the ceiling). Remember what I said earlier about wireless? When the day comes that you'll need it, you'll be glad you have a ready-to-use conduit that just needs you to cut a hole in the ceiling and grope around until you find the conduit. For line-of-sight wireless, you'll be glad you have the ceiling location.
If possible, run two conduits to non-adjacent walls in the bedrooms and living room. Don't forget the area under the wall cabinets in the kitchen and the snack bar.
Big tip: don't terminate the homerun from the wiring closet to the living room in a box behind your likely TV location. Put the box near a corner, in a spot likely to be easily accessible, then run another conduit from THERE to the box behind the TV. That way, if you someday have a 700 pound entertainment center blocking easy access to the box behind the TV and you bought some new toy that needs to have wiring pulled, you can temporarily pull it to the accessible box and play with it for a few days without having to deal with large-scale furniture movement.
That's probably because you've never done anything that's unsupported and unblessed by the chipset vendor.
Use case: rooted American Android phone. Gimped Broadcom radio driver that has FM reception disabled at carrier request, even though the hardware capability is present. Alternate.ko ripped from the European or International model's ROM dump and hacked to support American frequencies. Copy the.ko file to the phone, remount system as read/write, insmod.
Use case #2: rooted Sony Android phone. Camera crippled because Sony put the drivers for the advanced low-light and image-enhancement features in ARM TrustZone & throws away the encryption key if you unlock the bootloader via the Sony-blessed method. Acquire leaked files documenting what the code that was hidden away does, and build your own kernel module for the camera that implements everything in normal kernelspace (instead of TrustZone). Post to XDA, then go to bed happy, knowing that you're doing your part to fight The Man and bring Power to the People.;-)
The borderline-useless artificial construct college textbooks pretend is C++ for the sake of having something consistent and coherent to teach students for a few years at a time?
My point is that knowing "C++" (as an abstract, academic construct) barely equips you to do anything commercially useful with it. Probably 60% of what you need to know to do anything useful in C++ is platform-dependent, and another 20-30% is IDE-dependent (at least, in the Windows & Android realms, where trying to do anything independently of Visual Studio or Android Studio is an exercise in masochistic frustration (because both platforms are so tightly-coupled to their respective IDEs).
Android Studio beats Eclipse for Android development like an unloved child in a trailer park.
Seriously. Night-and-day improvement. No more times when you have to cut something into the clipboard, save the empty file, and paste it back to make Eclipse realize that it's imagining all the errors it thinks were in it. No more "type a semicolon, then have the cursor inexplicably move back so that the carriage return a moment later pushes the semicolon to the next line and breaks the code." No more situations where the IDE forgets what R.java is, where it came from, or how to regenerate it.
Just make sure you use the official Google version of Android Studio, and NOT IntelliJ. As I mentioned in an earlier post, IntelliJ 14 with the Jetbrains Android plugin is neither directly-equivalent nor a consequence-free superset of Android Studio.
Both are forks of a common ancestor, but the core IDE code bases diverge enough that Jetbrains basically has to backport Google's changes to IntelliJ every time there's a new release.
Maybe my opinion was skewed by horrible bugs in IntelliJ Pro 14.0.x that no longer exist in 14.1.x, but my advice is to just forget that IntelliJ Pro exists (even if you own a copy) and use Google's official Android Studio instead.
I never managed to successfully import an Eclipse Android project into IntelliJ. With Android Studio, it effortlessly worked on the first try.
Ditto, for creating a new app that used the Google Maps API. I fucked around with IntelliJ for WEEKS trying to get it to work, and had little besides inexplicable Gradle build errors to show for it. Android Studio automatically downloaded the SDK files it needed, and even made it blatantly obvious where I had to paste the API key.
For Android development, at least, Android Studio just feels a lot more refined, polished, and streamlined than IntelliJ.
Slashdot Mirror
And roughly ten thousand times as much agricultural land is lost in any given year to new office parks, golf courses, condos, and discount retail stores.
Spoiler: the desert is a great place to build sprawling metro areas (Las Vegas, Phoenix, Dubai, Salt Lake City...). The Sahara (just to name one) is really fucking huge, and it's unlikely to either flood or be covered in glaciers anytime within the next million years.
> The ground is water permeable.
So dig Florida-style finger canals to create new, valuable waterfront property to sell to foreigners for vacation homes, and use the revenue to pay for raising the rest of the main island for Kiribati's own residents.
Permeable ground just means you can't rely on levees or dikes to keep land that's below sea level dry. Raise the terrain itself (via dredged fill dirt) above sea level, and the problem is solved. The city of Chicago literally raised most of its land & buildings (and reversed the direction of the Chicago river) more than a hundred years ago. See: https://en.wikipedia.org/wiki/...
Guaranteed: if Kiribati were formally abandoned by its inhabitants and evacuated in some grand public gesture of eco-catastrophe, someone else (China, Russia, militant libertarians, etc) would show up, occupy the islands one by one, and declare ownership & sovereignty within a matter of days.
> The Russian won't be able to heat his home when the economy collapses due to climate change
Er.... out of all the countries on Earth, with the possible exception of Canada, I struggle to think of a country that's more likely to be a net beneficiary of climate change than Russia.
Obligatory joke: In Soviet Russia, climate changes YOU...
In theory, FTDI's USB-UART chips can bitbang... but AFAIK, no windows, Linux, or osx drivers have any kind of API for using it on a computer. You have to program the bare metal directly using a microcontroller. The catch is that due to the way USB modes work, the max usable rate is about 1 mbps... and that assumes a lockstep transfer of data AT 1mbps with fairly precise timing using isochronous mode. If you want to sample the pins at arbitrary rates, the max usable rate is about 1/64th of that (using "control" mode)... maybe less.
In theory, a FTDI chip capable of native USB3.0 with interrupts tied to an external clock line could probably bitbang SCSI-1, but AFAIK, they haven't made such a chip yet.
Long before they were creating special models for Black Friday, retailers like CompUSA and Circuit City were buying up laptops with known design flaws (like a model made with hard drives whose fucked-up firmware seemingly worked fine with FAT32, but would slowly mangle NTFS or EXT2... their excuse was that they never said it would work with anything besides the OS it shipped with (Windows 98, if I recall). Goddamn, I spent literally 3 weeks trying to figure out why Windows 2000 Pro would self-destruct within days every time I installed it on my Dad's new Black Friday laptop. When I found out the real reason, I was beyond livid. And it's a major reason why I now won't touch a Black Friday Sale laptop with a 10-foot dirty tetanus-infested pole, and will never trust the quality of HP's consumer-grade laptops again. I would have been totally fine with their offering the laptop at discounted prices IF they'd boldly disclosed on the box that the laptop was made with a hard drive that had defective firmware that would corrupt NTFS and EXT2... but they didn't. The mother fuckers just hoped that most people wouldn't notice.
I'm pretty sure that most of the "40 million" are sharing a SSN with somebody who died *years* ago, and that the number of people like the two women cited as an example is much, MUCH smaller.
I mean, for ${deity.name}'s sake, there are only ~300 million *AMERICANS*. If one in 8 Americans had SSN collisions with another living person, I can *guarantee* it wouldn't have taken until now to be newsworthy.
That said, the gov't really needs to add at least a digit or two. Just adding one digit & making every existing SSN end with "0" until 2025 (to allow a graceful transition where existing 9-digit numbers would have an easily-derived 10-digit value) would give them enough unique numbers to go a few centuries without ever reusing a number.
Is there any free rsync SERVER capable of running under 64-bit Windows 7 Pro and working with any known Android rsync client over wifi (to an ext2-formatted hard drive mounted using ext2fsd)?
If you efficiently collected 100% of the water dripping from a typical 3-5 ton South Florida central AC unit on a 90-degree day with 99% relative humidity, you MIGHT end up with enough water to flush a toilet once or twice. Maybe 5 gallons, if you were lucky.
As others have noted, Android's biggest performance problems come down to architectural compromises made *years* ago so Android could run (walk?) on 200Mhz devices with 480x320 displays and almost no RAM circa 2009. Just about everything Android does is PIO-based... and the closed nature of Qualcomm's chipsets means end users are still running on an ever-accelerating treadmill with every new device & version of Android just to have a working camera & GPS under the new (and 100% incompatible with binary .ko drivers) kernel every new version of Android inevitably demands.
Correction: Qualcomm has a near-monopoly on SoCs capable of doing LTE on American mobile networks in all licensed bands without additional chips. If you want a single-chip 4+ core Android device that works with 100% support for all relevant bands & data modes on Verizon, Sprint, or even AT&T, you basically have one viable choice: Qualcomm.
Renesas had a competitive alternative chipset ~2 years ago, but the new owners seem to have no real interest in trying to compete with Qualcomm in the US anymore for top-shelf flagship-class device5 and AFAIK are only now interested in the throwaway low-end.
SHA-1 hasn't been "defeated" -- at most, an attacker able to muster substantial computer resources *might* be able to discover a random binary file of random length that shares the same SHA-1 hash as something else.
In other words, there might be some denial-of-service potential if an attacker were able to forge the signature for an update file & trick a remote computer into replacing good files with nonworking ones, but that's pretty much *it* for the immediate future.
Should a new app use SHA-2? Of course. It's no harder to use, and bulletproof at this point. But there's no great urgency to replace SHA-1 in existing code at this point.
Actually, there's a well-established precedent for regulating private venues as de-facto public squares. See Pruneyard Shopping Center v. Robins [ https://en.wikipedia.org/wiki/... ]
And what's more valuable to an intelligence agency... someone with a neurotically-groomed token profile based on their "real" name, or someone with an extensive profile under a technically-fake name (a name that's practically a de-facto GUID because they use it in other parts of their daily lives)?
The ultimate nightmare scenario for the National Weather Service: a confirmed rain-wrapped EF0 tornado that touches down in Miami or Fort Lauderdale at 4pm & is clearly heading towards I-95. If they say nothing, the tornado is unlikely to kill anyone, because everyone will be driving slowly due to the torrential rain anyway. On the other hand, if they send out a warning that a tornado is about to cross I-95, some idiot is almost **guaranteed** to abandon his car, attempt to cross 4-6 lanes of traffic, and get run over (because it's still bumper-to-bumper 30-40mph traffic, but near-zero visibility). And probably trigger a 7-car pile-up in the process.
And if it's "automatic", almost by definition it's always online & thus vulnerable to a potentially WORSE (insofar as data recovery is concerned) mode of failure... encryption by ransomware.
Seriously. Name one... ONE... NAS or online backup solution that allows continuous adhoc writing, but acts like a virtual WORM filesystem and merely marks obsolete files as 'deleted' without actually deleting them, so that any attempt by ransomware to encrypt the files on the backup drive would simply fill up the drive until the ransomware crashed (and quite possibly provide an early warning of what it was up to).
In some ways, it feels like we've gone backwards over the past 20 years. Capacities have increased exponentially, but new hard drives seem to drop like flies compared to drives from 10-20 years ago. And often, they fail in creative ways that RAID (1, 5, 10, or whatever) can't save you from (golden example: OCZ's second-generation SSDs with Sandforce controllers that simultaneously omitted the supercapacitor needed to make sure the drive never lost power during writes (to save about a dollar per drive) AND disabled the multi-step safety measures Sandforce built into the default firmware (because it made the drives slow).
I personally threw in the towel on C++ for AVRs when I found out that the only way to create instances of an object was an abomination like:
DesiredObjectType* ptrObjectType = (DesiredObjectType*) malloc(sizeof(DesiredObjectType));
or something to that effect. I don't remember whether it was just a temporary work-around to a bug in the current version of GCC, or something more fundamental... but it totally turned me off. I went back to assembly. It was easier, and made more sense.
The catch is, not all devices (especially devices more than a few years old) ARE "sanely designed". I remember quite well that the original Palm III had fairly demanding battery requirements... it was good for about a month with Duracell or Energizer alkalines, but only lasted 2-3 weeks with store-brand alkaline cells, and only lasted a few DAYS with NiMH cells. Ditto for my piece-of-shit Minolta d'Image DSLR, which was good for about 10 photos on brand new alkaline batteries before shutdown.
That said, the marketers behind this aren't being entirely honest... they're presenting the best-possible and most extreme edge case as the universal norm. It will make a HUGE difference for some (badly-designed/cost-cut) devices, and make no positive difference for well-designed devices. Regardless, it'll be useful, because shit devices vastly outnumber well-designed ones.
Fiber of any kind is a waste of money unless you already know what you're going to terminate it with at both ends. Fiber might be "future-proof" in the sense that someone, someday, will make converter boxes to let you use older fiber for new purposes... but I can guarantee that any such conversion box will end up costing WAY more than you'd have likely spent just buying a spool of new fiber and pulling it through a conduit. That's why conduit is so great. You don't HAVE to try and guess an unpredictable future, and spend eternity putting band-aids on your mistakes from 20 years ago. Put in conduit, and you can pull whatever you need, when you eventually need it.
Conduit. The future might be wireless, but the wireless you'll have to use won't be able to penetrate a window, much less a wall. Conduit will allow you to pull cheap cat5e today, and replace it with fiber 10-20 years from now when you finally NEED it.
Run conduit to every room where you think you might someday want to have a network connection, or need to put a line-of-sight access point. Don't forget the bathrooms, garage, basement, and snack bar in the kitchen.
From at least one box in each room where you're terminating the low-voltage conduit, run another conduit up to somewhere on the ceiling about a foot or two from the wall. You can omit the boxes and just leave the conduit there (photographed and documented for future reference), but they'll make your life INFINITELY easier if you someday need to put an access point on the ceiling). Remember what I said earlier about wireless? When the day comes that you'll need it, you'll be glad you have a ready-to-use conduit that just needs you to cut a hole in the ceiling and grope around until you find the conduit. For line-of-sight wireless, you'll be glad you have the ceiling location.
If possible, run two conduits to non-adjacent walls in the bedrooms and living room. Don't forget the area under the wall cabinets in the kitchen and the snack bar.
Big tip: don't terminate the homerun from the wiring closet to the living room in a box behind your likely TV location. Put the box near a corner, in a spot likely to be easily accessible, then run another conduit from THERE to the box behind the TV. That way, if you someday have a 700 pound entertainment center blocking easy access to the box behind the TV and you bought some new toy that needs to have wiring pulled, you can temporarily pull it to the accessible box and play with it for a few days without having to deal with large-scale furniture movement.
That's probably because you've never done anything that's unsupported and unblessed by the chipset vendor.
Use case: rooted American Android phone. Gimped Broadcom radio driver that has FM reception disabled at carrier request, even though the hardware capability is present. Alternate .ko ripped from the European or International model's ROM dump and hacked to support American frequencies. Copy the .ko file to the phone, remount system as read/write, insmod.
Use case #2: rooted Sony Android phone. Camera crippled because Sony put the drivers for the advanced low-light and image-enhancement features in ARM TrustZone & throws away the encryption key if you unlock the bootloader via the Sony-blessed method. Acquire leaked files documenting what the code that was hidden away does, and build your own kernel module for the camera that implements everything in normal kernelspace (instead of TrustZone). Post to XDA, then go to bed happy, knowing that you're doing your part to fight The Man and bring Power to the People. ;-)
Define what you mean by "C++".
C++ firmware for an Atmel AVR microcontroller?
C++ native Android loadable kernel module?
C++ MFC Windows app?
C++ hardware driver for Windows?
C++ Linux app built for GTK+?
The borderline-useless artificial construct college textbooks pretend is C++ for the sake of having something consistent and coherent to teach students for a few years at a time?
My point is that knowing "C++" (as an abstract, academic construct) barely equips you to do anything commercially useful with it. Probably 60% of what you need to know to do anything useful in C++ is platform-dependent, and another 20-30% is IDE-dependent (at least, in the Windows & Android realms, where trying to do anything independently of Visual Studio or Android Studio is an exercise in masochistic frustration (because both platforms are so tightly-coupled to their respective IDEs).
Android Studio beats Eclipse for Android development like an unloved child in a trailer park.
Seriously. Night-and-day improvement. No more times when you have to cut something into the clipboard, save the empty file, and paste it back to make Eclipse realize that it's imagining all the errors it thinks were in it. No more "type a semicolon, then have the cursor inexplicably move back so that the carriage return a moment later pushes the semicolon to the next line and breaks the code." No more situations where the IDE forgets what R.java is, where it came from, or how to regenerate it.
Just make sure you use the official Google version of Android Studio, and NOT IntelliJ. As I mentioned in an earlier post, IntelliJ 14 with the Jetbrains Android plugin is neither directly-equivalent nor a consequence-free superset of Android Studio.
One warning -- Android Studio != IntelliJ Pro
Both are forks of a common ancestor, but the core IDE code bases diverge enough that Jetbrains basically has to backport Google's changes to IntelliJ every time there's a new release.
Maybe my opinion was skewed by horrible bugs in IntelliJ Pro 14.0.x that no longer exist in 14.1.x, but my advice is to just forget that IntelliJ Pro exists (even if you own a copy) and use Google's official Android Studio instead.
I never managed to successfully import an Eclipse Android project into IntelliJ. With Android Studio, it effortlessly worked on the first try.
Ditto, for creating a new app that used the Google Maps API. I fucked around with IntelliJ for WEEKS trying to get it to work, and had little besides inexplicable Gradle build errors to show for it. Android Studio automatically downloaded the SDK files it needed, and even made it blatantly obvious where I had to paste the API key.
For Android development, at least, Android Studio just feels a lot more refined, polished, and streamlined than IntelliJ.
> I think more of the problem is so much stuff gets sent by truck when rail would be cheaper and faster.
Er.... I assume you've seen THESE, which seem to address your concerns quite thoroughly:
http://www.railpictures.net/im...
https://www.youtube.com/watch?...