Many *MANY* years ago I was working as a software engineer at Philips Research in the early 1980's when they were looking into ISDN systems somewhat like DSL for the UK market - the business of sending anything over twisted pair copper is a nightmare. I wasn't directly working on the electronics (I was doing software) - but I shared an office with people who did...and they had a heck of a time characterizing the wires that their signals had to go down.
As I recall, the problems mostly come where one wire is spliced into another. Much of this infrastructure was put in the 1900's and it's horrible. Sometimes wires are just twisted together and capped, sometimes twisted and taped, sometimes twisted and just left open to the elements, sometimes they are soldered. Sometimes the places where the wires are joined gets wet when it rains. Sometimes the tightness of the twisted wire connection depends on the ambient temperature. The amount of cross-talk between wires is all over the map as different kinds of insulation was used (and much of it has degraded over the years). At the subscriber end, there were all kinds of phones being used - plus ugly stuff like "Party lines" (where two houses share a phone line!) that had been abandoned leaving extra wires in the ground that were still connected to the network.
All of those things affect the ability to get a decent amount of bandwidth down a wire that was never designed to do it. So the electronics has to be smart about the signal being reflected at each splice down the line and causing 'echoes', and designing affordable circuitry to detect and cancel those echoes was a nightmare. The amount of attenuation you'll get is all over the map - everything has to self- adjust and monitor to give it any chance of working.
So, as poor as DSL can be - it's a miracle it works at all over crappy old telephone wires.
I like the idea of a browser for the front end, only because browsers are omnipresent and does not require installing potentially harmful code. However, apps are completely different, if only in that the code would require downloading, regardless.
The problem isn't "going to the moon" - the problem is staying there long enough to do something useful while you're there. What was done in the original Moon missions could be done much more efficiently with robots.
The things we need people for is much more long-term - and the Apollo technology couldn't do that.
I don't buy the argument that the moon is a good stepping stone to Mars - the difficulty of creating and maintaining all the infrastructure to manufacture rocket fuel and get it up into lunar orbit (or back to Earth orbit) is way harder than just going to Mars.
Mars has more gravity, a source of CO2 for plants, a sane day length (also for plants), water (probably) just underground rather than in the shadow of the rim of some craters that never see sunlight (which might be kinda hard to work in, don't you think?)
At the very least, I'd want to see a robot crawl across a lunar crater and take a photo of the water ice piled up there before we made any kind of a judgement as to how useful the moon is.
The main reason I see to go there is to collect Helium 4 for fusion reactors...and then the water would be a bonus. That's a commercial opportunity that a big company could actually go and exploit.
I hate Java, i hate Android development, but i repeat myself. And that's exactly what i hate about them.
In Android, objects have their own namespaces, under R. There's R.class, R.mipmap, R.layout, R.color, R.integer, and many more. So, the namespace of the layout (where you usually add objects) is under R.layout, the image on a button can be under R.mipmap. Nice.
It has indeed been around for a long time. Some years much, much better than others. Unfortunately, over time, things got much less subtle, and far too repetitive.
Too many people are thinking of security instead of opportunity. They seem more afraid of life than death. -- James F. Byrnes