Okay, I'm oversimplifying. It has to be powered all of the time unless you want to have aggressive suspend modes and do hot-swap tricks to reduce power consumption while on battery power.
and 32gb of ddr4 draws less than 32gb of ddr3 and has more power saving options
32GB of DDR4 draws less power than 32GB of DDR3, but a lot more power than 32GB of LPDDR3. The Intel chips support LPDDR3, DDR3 and DDR4. They only support 32GB with DDR4. 32GB of LPDDR4 would be fine, but the CPUs don't support this.
Yes, exactly. And $15/hr is not assuming that the cars have passengers for that whole hour. It is assuming that they make an average of $15 per hour. You assumed that this meant full occupancy for that time, and then proceeded to rant about assumption that the original poster had not made.
It's not even news. In his interview with John Oliver, he mentioned that Russian Intelligence was watching who came to meet with him. It's not like he's been trying to pretend that this isn't happening, and he knew it would happen which is why he didn't take any of the data with him to Russia.
Supplied by Russia? Did you read how their accounts were compromised? Someone sent a really obvious phishing spam to John Podesta, someone in the Democratic party whose job was to review suspicious emails said that it was important to click on the link, and the recipient did. Nothing in that requires a state-level actor, a teenage kid could have done it. I'd be a lot more willing to believe that Russia (as a nation state, rather than as a country that happens to contain some bored kids) was involved.
In this case, it's more Intel. I don't care about the soldered-on SSD: a 2TB SSD should last the life of the machine and if it dies before then I want Apple to replace it under warranty, so I don't care if it costs them more to replace. 16GB is the deal breaker though. We have roughly a three-year upgrade program at work and my current MBP is now three years old. We have the money to buy a replacement, but for a lot of what I do RAM is the bottleneck. I completely understand why Apple couldn't bump the maximum to 32GB: Intel chips don't support 16GB of LPDDR3, only DDR4, 32GB of which would consume the battery at too high a rate (especially given that RAM has to be powered all of the time). The next generation of Intel chips will do LPDDR4, so this should become a non-issue. I'm hoping that they'll do a small bump in six months and release 32GB versions.
It's assuming 20 hours per day, 7 days a week, 50 weeks a year, with an average of 1/6 utilisation. That's how you make his maths work. His $105,000 is 20 (hours) * 7 (days) * 50 (weeks) * 15 (dollars). Uber charges about $15 for a 10 minute trip, so he's assuming 10 minutes of passenger carrying for each hour on the road.
Going into this assuming a constant 20 hour per day usage of every car in the fleet is called looking at things with rose colored glasses.
He isn't, he's assuming an average of 20 hours at $15/hour. Given their current rates, that's assuming that about 10 minutes of each of those hours will be spent transporting a passenger. At peak times, it's going to be a lot more.
fork() exploits the MMU by marking every page in the parent process as readonly, then sharing these pages with the child process. There is no immediate copying of memory.
That's not quite true: at the very least, the top stack frame will be copied immediately. That set of MMU updates also isn't cheap on a modern multicore system (you have to flush all of the relevant pages from all of the TLBs). More importantly, there's a lot of in-kernel state for a process (e.g. file descriptor tables) that gets duplicated when you fork a process.
If it works how some scientists think it works, that would indeed rewrite the laws of physics as we know them -- and this is scary
Why is it scary? The physical models we have now are good enough for all of the machines that we've built (indeed, many of them are fine with models a few centuries old). Stuff isn't going to break as a result of this, but stuff that we'd previously thought was impossible now might turn out not to be and physicists have a lot more work to do to create models that explain them. That's a pretty exciting, but not very scary.
Uh, the shadow of what? Of Earth? No, because the Earth rotates. Of the support cable? Okay, so now the rest of the elevator is getting warm and needs to dissipate that heat somehow (most likely by achieving an equilibrium temperature and radiating).
so it is close to absolute zero cold
Nope, you seem to fundamentally misunderstand how thermodynamics works. The temperature is cold in the shade on Earth because you are surrounded by an atmosphere and heat convects away from you. This does not happen in space. Any energy that hits you must be radiated away to maintain a constant temperature. If the ribbon is in sunlight (which it will be for most of the time, only briefly being shaded in its entirety for a few minutes) then it must radiate roughly 1kW per square metre. You can work out the temperature that it'll reach at equilibrium yourself, but it definitely won't be cold enough for any existing superconductors (including ones that exist only in the lab).
That would be factor ten, so easy achieved by a solar panel 10 times bigger.
Even if it's only a factor of ten (it isn't), making it ten times bigger makes it (at least) ten times heavier, and now you can't support it on the ribbon (or carry it on the crawler).
Please go and read some of the papers on space elevator design. The maths isn't that complicated and people have spent years thinking through some of these problems.
virtually every ARM system requires a custom OS build.
That's not really true. With FDT (or ACPI in ARMv8), kernels can auto-configure. It's only older (pre-ARMv7) systems that need a lot of system configuration. We have had working generic ARM kernels for FreeBSD for a while now.
Few will extend the architecture in non-standard ways, because of the trouble that entails in the toolchain
This is exactly what happened with MIPS. People extended it and provided their own GCC version. The GCC changes were never upstreamed because, in most cases, they broke other MIPS targets. The vendors didn't maintain them, so you're always stuck with some vendor's old GCC version and all of the bugs that it brings. ARM managed to avoid this, encouraging people to move the innovation to other cores on the SoC.
It's especially annoying as there are idioms that will force all major JavaScript implementations to treat a value as a 32-bit integer, yet none that will work properly for 64-bit arithmetic, because the standard explicitly prohibits providing more than IEEE 64-bit floating point precision. It's even more annoying when you use the TypedArray types, where you can load and store 32-bit floats, 64-bit floats, 8-, 16-, and 32-bit (signed and unsigned) integers, but you can't even store 64-bit values - you have to treat them as a pair of 32-bit integers and perform your calculations as if you were dealing with a bignum.
The depressing thing is that Smalltalk solved this for dynamic languages sensibly in the '70s. Smalltalk had SmallInt objects that were embedded in pointers and were transparently promoted to BigInt objects on overflow. It also has a family of Float classes that implement fixed-precision floating point values (either the IEEE standard sizes or user-defined sizes if you'd prefer to trade speed for more precision).
The current mechanism has a human in the loop, but they only have a second or two to decide whether to press the button to fire at the computer-selected targets or not. It's not really long enough to make an informed decision, and the military generally considers accidental civilian casualties that result to be acceptable collateral damage. Having the system make the fire decision would probably cut down PTSD cases, as no human would have hit the kill button the times it hits civilians.
Unfortunately, a lot of that R&D is dual use. Self-driving cars will require the same navigation systems as autonomous robots. Remote-controlled drones will require the same chassis and control hardware as autonomous versions. Even the targeting systems can be developed under the ban: the difference between the system on the Apache that can target and prioritise a few hundred targets for the human gunner and one that then fires at the highest priority targets itself is a couple of lines of code. There isn't much that you need to build an autonomous robot soldier that you don't need for something else that such a treaty would permit. It's then just the final assembly step that's needed, and doing that in secret doesn't need too many people to know about it.
US gear only falls into the hands of our enemies in 2 scenarios: we sell it to them, or it gets seized from our allies
Actually, there's another third common scenario: You sell it to your 'allies' (you know, nice friendly countries like Saudi Arabia) and they sell it on, leaving you with no control over its final destination.
And if you want to see what happens when they don't, look at what happened to MIPS. Every MIPS vendor implemented their own extensions and you have a choice between portable code and code that runs at a reasonable speed. In contrast, ARM binaries run on any ARM system. RISC-V still hasn't yet designated different parts of their NOP space for trapping and non-trapping NOPs, so extension is going to be difficult, and the RISC-V Foundation still doesn't have a process for introducing extensions for review and standardisation. This is why the ARM ecosystem is so valuable and the MIPS ecosystem is a wasteland.
Most of those issues are ones of taste, not significant barriers. The real problem with JavaScript is that it has a single numerical type, and that type is a stupid choice. You can't do 64-bit integer arithmetic in JavaScript in a remotely sane way.
Microsoft has released a CLR implementation under an MIT license, has put everything required to implement the CLR into an ECMA standard, and has released a public promise not to sue for any patents involved in the implementation of a CLR. Some of the APIs are exempt, but these are largely the Windows-specific ones. If you write portable C# code, then it's basically impossible for Microsoft to sue anyone that provides you with a platform on which to run it. Oracle has shown that this is not true for Java.
OS X uses almost exactly the same.app bundle format as NeXTSTEP. If there were any patents, they'd have expired in 2008 at the latest. That said, this doesn't sound much like the bundle format, it sounds more like the PC-BSD package format.
Space isn't cold. Cold isn't a concept that exists in a vacuum. The cable will be in direct sunlight, receiving energy and warming, and will be unable to cool by radiating heat. For existing space stations and space craft, dissipating heat, not staying warm, is the big engineering problem.
OTOH, the proposed carbon nanofibres are very good conductors anyway, so probably there are no extra cables needed?
Only in single strands. Electricity flows along the tube, which is what makes them good conductors, but it also means that you can't make good wires by bundling them together. It also means that you can't easily tap the power anywhere other than the ends of the chains.
Anyway: considering that beaming basically means beaming light/probably a laser, the receiver will be a solar panel. Why not using that panel for sun/solar power instead?
Because the solar energy hitting is about 1Kw/m^2, the energy from the laser beam is an order of magnitude or so higher.
If you want something really private, why use a 3rd party hosting service?
How much do you have to spend on system administrators to keep the server that's hosting your stuff secure? For small organisations, the cost of GitHub is a lot lower than the cost of a private repository with the same level of security.
Lots of things (though a lot of them can be replicated by running GOGS or GitLab on your own machine):
The most valuable thing is a single sign-on service. I leave a lot more bug reports for open source projects if they're on GitHub: their issue tracker isn't the best, but it doesn't require me to create a new account. The same thing if I want to submit patches: I don't need to subscribe to mailing lists or similar, I just clone the repo, send a pull request, and it's done.
Every GitHub project has an issue tracker, a web site, and a wiki, all hosted by GitHub. The issue tracker is integrated with the commit log, so I can close issues by simply putting 'Fixes #42' in the commit message and have things automatically cross referenced. The wiki is a git repo, so I don't have to use crappy wiki editing tools, I can clone the repo and edit the files in my favourite text editor. The web site can either be static HTML that you generate and put in a git repo, or it can use Jekyll to generate the HTML from other markup languages on the GitHub servers.
The pull request mechanism is the thing that GitHub is most well known for. It's closely related to the discussion and code review interface that is the core of the GitHub site. If someone sends a pull request, I can review their code, comment on it, discuss high-level design choices in a thread that's attached to the pull request, and merge it, all from the web interface.
GitHub exposes a bunch of web APIs that other services use (for example, you can get notifications whenever there's a push to a particular repo). For example, I can set up Coverity scans or use Travis-CI to run the test suite on every commit. Even better, things like Travis integrate with pull requests, so even before I start to review code, I can see if it passes tests. This is even better if the pull request comes with new tests: I can see that they pass, without even doing a checkout.
GitHub provides private repos, so once you are familiar with the interface, you can use it for internal projects.
GitHub will generate tarballs from any commit (and they are quick to download). We use this in the FreeBSD ports collection for a load of things. If I want to package something that's on GitHub, it's two lines to specify that it's from GitHub and what commit hash I want and the build system can grab a tarball of that revision and turn it into a package.
A long power line and a solar plant on top of it is enough.
What material would you make the power line from where the losses over 35,800 km are sufficiently small that it would deliver a useful amount of power? Actually, assume a power plant at the bottom as well, you only need resistive losses to be under 2% for 17,900km. For reference, the longest power transmission line in the world currently is a high-voltage DC line that is 2,385km long. Current HVDC lines have losses of about about 3.5% per 1,000 km, so that's over a 60% loss over half the length of the cable, but the weight of the line is such that it would be completely impossible to build.
Or as soon as we are out of the atmosphere, a smaller solar plant every 100km.
Do you have any idea how much weight that would add to the cable? You're talking about adding over 350 power stations along the length, each of which would be several tons. As with your first idea, that pushes the required strength of the cable far beyond anything that we can even model and predict the properties of, let alone produce in experimental quantities in a lab.
Beaming power to the "crawler/climber" is a SF concept that does not really make sense.
And yet it's the design that people investing in space elevator development (including NASA) are pushing.
Cloud cover isn't necessarily a problem for solar, as the frequencies blocked by the clouds are not the ones that PV cells are most efficient at collecting. You'll see some decrease, but not as much as you might think. Add to that the fact that PV cells become a lot less efficient if they get too hot and sometimes cloudy days can generate more power than sunny ones: less light hits the cells, but they're more efficient at converting it to electricity.
Slashdot Mirror
no it does not.
Okay, I'm oversimplifying. It has to be powered all of the time unless you want to have aggressive suspend modes and do hot-swap tricks to reduce power consumption while on battery power.
and 32gb of ddr4 draws less than 32gb of ddr3 and has more power saving options
32GB of DDR4 draws less power than 32GB of DDR3, but a lot more power than 32GB of LPDDR3. The Intel chips support LPDDR3, DDR3 and DDR4. They only support 32GB with DDR4. 32GB of LPDDR4 would be fine, but the CPUs don't support this.
Yes, exactly. And $15/hr is not assuming that the cars have passengers for that whole hour. It is assuming that they make an average of $15 per hour. You assumed that this meant full occupancy for that time, and then proceeded to rant about assumption that the original poster had not made.
It's not even news. In his interview with John Oliver, he mentioned that Russian Intelligence was watching who came to meet with him. It's not like he's been trying to pretend that this isn't happening, and he knew it would happen which is why he didn't take any of the data with him to Russia.
Supplied by Russia? Did you read how their accounts were compromised? Someone sent a really obvious phishing spam to John Podesta, someone in the Democratic party whose job was to review suspicious emails said that it was important to click on the link, and the recipient did. Nothing in that requires a state-level actor, a teenage kid could have done it. I'd be a lot more willing to believe that Russia (as a nation state, rather than as a country that happens to contain some bored kids) was involved.
In this case, it's more Intel. I don't care about the soldered-on SSD: a 2TB SSD should last the life of the machine and if it dies before then I want Apple to replace it under warranty, so I don't care if it costs them more to replace. 16GB is the deal breaker though. We have roughly a three-year upgrade program at work and my current MBP is now three years old. We have the money to buy a replacement, but for a lot of what I do RAM is the bottleneck. I completely understand why Apple couldn't bump the maximum to 32GB: Intel chips don't support 16GB of LPDDR3, only DDR4, 32GB of which would consume the battery at too high a rate (especially given that RAM has to be powered all of the time). The next generation of Intel chips will do LPDDR4, so this should become a non-issue. I'm hoping that they'll do a small bump in six months and release 32GB versions.
It's assuming 20 hours per day, 7 days a week, 50 weeks a year, with an average of 1/6 utilisation. That's how you make his maths work. His $105,000 is 20 (hours) * 7 (days) * 50 (weeks) * 15 (dollars). Uber charges about $15 for a 10 minute trip, so he's assuming 10 minutes of passenger carrying for each hour on the road.
Going into this assuming a constant 20 hour per day usage of every car in the fleet is called looking at things with rose colored glasses.
He isn't, he's assuming an average of 20 hours at $15/hour. Given their current rates, that's assuming that about 10 minutes of each of those hours will be spent transporting a passenger. At peak times, it's going to be a lot more.
Taxi drivers can retrain and get better jobs
If retraining and getting a better job is an option for unemployed taxi drivers, why isn't it a good option for employed taxi drivers?
fork() exploits the MMU by marking every page in the parent process as readonly, then sharing these pages with the child process. There is no immediate copying of memory.
That's not quite true: at the very least, the top stack frame will be copied immediately. That set of MMU updates also isn't cheap on a modern multicore system (you have to flush all of the relevant pages from all of the TLBs). More importantly, there's a lot of in-kernel state for a process (e.g. file descriptor tables) that gets duplicated when you fork a process.
If it works how some scientists think it works, that would indeed rewrite the laws of physics as we know them -- and this is scary
Why is it scary? The physical models we have now are good enough for all of the machines that we've built (indeed, many of them are fine with models a few centuries old). Stuff isn't going to break as a result of this, but stuff that we'd previously thought was impossible now might turn out not to be and physicists have a lot more work to do to create models that explain them. That's a pretty exciting, but not very scary.
The cable will be in the shadows,
Uh, the shadow of what? Of Earth? No, because the Earth rotates. Of the support cable? Okay, so now the rest of the elevator is getting warm and needs to dissipate that heat somehow (most likely by achieving an equilibrium temperature and radiating).
so it is close to absolute zero cold
Nope, you seem to fundamentally misunderstand how thermodynamics works. The temperature is cold in the shade on Earth because you are surrounded by an atmosphere and heat convects away from you. This does not happen in space. Any energy that hits you must be radiated away to maintain a constant temperature. If the ribbon is in sunlight (which it will be for most of the time, only briefly being shaded in its entirety for a few minutes) then it must radiate roughly 1kW per square metre. You can work out the temperature that it'll reach at equilibrium yourself, but it definitely won't be cold enough for any existing superconductors (including ones that exist only in the lab).
That would be factor ten, so easy achieved by a solar panel 10 times bigger.
Even if it's only a factor of ten (it isn't), making it ten times bigger makes it (at least) ten times heavier, and now you can't support it on the ribbon (or carry it on the crawler).
Please go and read some of the papers on space elevator design. The maths isn't that complicated and people have spent years thinking through some of these problems.
virtually every ARM system requires a custom OS build.
That's not really true. With FDT (or ACPI in ARMv8), kernels can auto-configure. It's only older (pre-ARMv7) systems that need a lot of system configuration. We have had working generic ARM kernels for FreeBSD for a while now.
Few will extend the architecture in non-standard ways, because of the trouble that entails in the toolchain
This is exactly what happened with MIPS. People extended it and provided their own GCC version. The GCC changes were never upstreamed because, in most cases, they broke other MIPS targets. The vendors didn't maintain them, so you're always stuck with some vendor's old GCC version and all of the bugs that it brings. ARM managed to avoid this, encouraging people to move the innovation to other cores on the SoC.
It's especially annoying as there are idioms that will force all major JavaScript implementations to treat a value as a 32-bit integer, yet none that will work properly for 64-bit arithmetic, because the standard explicitly prohibits providing more than IEEE 64-bit floating point precision. It's even more annoying when you use the TypedArray types, where you can load and store 32-bit floats, 64-bit floats, 8-, 16-, and 32-bit (signed and unsigned) integers, but you can't even store 64-bit values - you have to treat them as a pair of 32-bit integers and perform your calculations as if you were dealing with a bignum.
The depressing thing is that Smalltalk solved this for dynamic languages sensibly in the '70s. Smalltalk had SmallInt objects that were embedded in pointers and were transparently promoted to BigInt objects on overflow. It also has a family of Float classes that implement fixed-precision floating point values (either the IEEE standard sizes or user-defined sizes if you'd prefer to trade speed for more precision).
The current mechanism has a human in the loop, but they only have a second or two to decide whether to press the button to fire at the computer-selected targets or not. It's not really long enough to make an informed decision, and the military generally considers accidental civilian casualties that result to be acceptable collateral damage. Having the system make the fire decision would probably cut down PTSD cases, as no human would have hit the kill button the times it hits civilians.
Unfortunately, a lot of that R&D is dual use. Self-driving cars will require the same navigation systems as autonomous robots. Remote-controlled drones will require the same chassis and control hardware as autonomous versions. Even the targeting systems can be developed under the ban: the difference between the system on the Apache that can target and prioritise a few hundred targets for the human gunner and one that then fires at the highest priority targets itself is a couple of lines of code. There isn't much that you need to build an autonomous robot soldier that you don't need for something else that such a treaty would permit. It's then just the final assembly step that's needed, and doing that in secret doesn't need too many people to know about it.
US gear only falls into the hands of our enemies in 2 scenarios: we sell it to them, or it gets seized from our allies
Actually, there's another third common scenario: You sell it to your 'allies' (you know, nice friendly countries like Saudi Arabia) and they sell it on, leaving you with no control over its final destination.
However, ARM still maintains control
And if you want to see what happens when they don't, look at what happened to MIPS. Every MIPS vendor implemented their own extensions and you have a choice between portable code and code that runs at a reasonable speed. In contrast, ARM binaries run on any ARM system. RISC-V still hasn't yet designated different parts of their NOP space for trapping and non-trapping NOPs, so extension is going to be difficult, and the RISC-V Foundation still doesn't have a process for introducing extensions for review and standardisation. This is why the ARM ecosystem is so valuable and the MIPS ecosystem is a wasteland.
Most of those issues are ones of taste, not significant barriers. The real problem with JavaScript is that it has a single numerical type, and that type is a stupid choice. You can't do 64-bit integer arithmetic in JavaScript in a remotely sane way.
Microsoft has released a CLR implementation under an MIT license, has put everything required to implement the CLR into an ECMA standard, and has released a public promise not to sue for any patents involved in the implementation of a CLR. Some of the APIs are exempt, but these are largely the Windows-specific ones. If you write portable C# code, then it's basically impossible for Microsoft to sue anyone that provides you with a platform on which to run it. Oracle has shown that this is not true for Java.
OS X uses almost exactly the same .app bundle format as NeXTSTEP. If there were any patents, they'd have expired in 2008 at the latest. That said, this doesn't sound much like the bundle format, it sounds more like the PC-BSD package format.
As space is relatively cold
Space isn't cold. Cold isn't a concept that exists in a vacuum. The cable will be in direct sunlight, receiving energy and warming, and will be unable to cool by radiating heat. For existing space stations and space craft, dissipating heat, not staying warm, is the big engineering problem.
OTOH, the proposed carbon nanofibres are very good conductors anyway, so probably there are no extra cables needed?
Only in single strands. Electricity flows along the tube, which is what makes them good conductors, but it also means that you can't make good wires by bundling them together. It also means that you can't easily tap the power anywhere other than the ends of the chains.
Anyway: considering that beaming basically means beaming light/probably a laser, the receiver will be a solar panel. Why not using that panel for sun/solar power instead?
Because the solar energy hitting is about 1Kw/m^2, the energy from the laser beam is an order of magnitude or so higher.
If you want something really private, why use a 3rd party hosting service?
How much do you have to spend on system administrators to keep the server that's hosting your stuff secure? For small organisations, the cost of GitHub is a lot lower than the cost of a private repository with the same level of security.
The most valuable thing is a single sign-on service. I leave a lot more bug reports for open source projects if they're on GitHub: their issue tracker isn't the best, but it doesn't require me to create a new account. The same thing if I want to submit patches: I don't need to subscribe to mailing lists or similar, I just clone the repo, send a pull request, and it's done.
Every GitHub project has an issue tracker, a web site, and a wiki, all hosted by GitHub. The issue tracker is integrated with the commit log, so I can close issues by simply putting 'Fixes #42' in the commit message and have things automatically cross referenced. The wiki is a git repo, so I don't have to use crappy wiki editing tools, I can clone the repo and edit the files in my favourite text editor. The web site can either be static HTML that you generate and put in a git repo, or it can use Jekyll to generate the HTML from other markup languages on the GitHub servers.
The pull request mechanism is the thing that GitHub is most well known for. It's closely related to the discussion and code review interface that is the core of the GitHub site. If someone sends a pull request, I can review their code, comment on it, discuss high-level design choices in a thread that's attached to the pull request, and merge it, all from the web interface.
GitHub exposes a bunch of web APIs that other services use (for example, you can get notifications whenever there's a push to a particular repo). For example, I can set up Coverity scans or use Travis-CI to run the test suite on every commit. Even better, things like Travis integrate with pull requests, so even before I start to review code, I can see if it passes tests. This is even better if the pull request comes with new tests: I can see that they pass, without even doing a checkout.
GitHub provides private repos, so once you are familiar with the interface, you can use it for internal projects.
GitHub will generate tarballs from any commit (and they are quick to download). We use this in the FreeBSD ports collection for a load of things. If I want to package something that's on GitHub, it's two lines to specify that it's from GitHub and what commit hash I want and the build system can grab a tarball of that revision and turn it into a package.
A space elevator does not need power beaming.
A long power line and a solar plant on top of it is enough.
What material would you make the power line from where the losses over 35,800 km are sufficiently small that it would deliver a useful amount of power? Actually, assume a power plant at the bottom as well, you only need resistive losses to be under 2% for 17,900km. For reference, the longest power transmission line in the world currently is a high-voltage DC line that is 2,385km long. Current HVDC lines have losses of about about 3.5% per 1,000 km, so that's over a 60% loss over half the length of the cable, but the weight of the line is such that it would be completely impossible to build.
Or as soon as we are out of the atmosphere, a smaller solar plant every 100km.
Do you have any idea how much weight that would add to the cable? You're talking about adding over 350 power stations along the length, each of which would be several tons. As with your first idea, that pushes the required strength of the cable far beyond anything that we can even model and predict the properties of, let alone produce in experimental quantities in a lab.
Beaming power to the "crawler/climber" is a SF concept that does not really make sense.
And yet it's the design that people investing in space elevator development (including NASA) are pushing.
Cloud cover isn't necessarily a problem for solar, as the frequencies blocked by the clouds are not the ones that PV cells are most efficient at collecting. You'll see some decrease, but not as much as you might think. Add to that the fact that PV cells become a lot less efficient if they get too hot and sometimes cloudy days can generate more power than sunny ones: less light hits the cells, but they're more efficient at converting it to electricity.