If you're looking for a break down of what pings look like globally, we've got the data: http://wondernetwork.com/pings

Or for Honolulu specifically: https://wondernetwork.com/ping... (101ms to Chicago)

The slashdot poster sounds sympathetic to it as a free speech warning or something, but I don't see how to read it as anything but a threat.

Maybe I missed something.

Hi,

I own https://wonderproxy.com/ and the primary thing we sell our customers is "a server where we say it is so you can test your localization", and we have problems _all the time_. So I've been where you are, with the added bonus of having customers yelling at me because Google thinks my Madrid server is in France.

There's no real good options here, different people use different databases of different ages with different procedures to update (if they have one at all). MaxMind (http://maxmind.com) is pretty good at updates, as are most of the free options (like ip2location http://www.ip2location.com/). Google (which powers a lot of ads, and their own country redirect) has a form (https://support.google.com/websearch/contact/ip) which seems to pipe directly into /dev/null.

Most GeoIP providers want to handle things in large blocks, not one IP at a time. If you can convince your ISP (generally by pointing them at a few forms) to send in corrections they'll be able to correct their entire IP space all at once, which may be handled faster, or at least cover you now and next time your IP changes. Once these are submitted expect a delay of 2weeks -> before anything starts to get better.

Beyond trying to correct people, buying a cheap server from Linode and VPNing through should be a decent work around. If you set up an OpenVPN server, several routers are capable of connecting and routing all their data through them automatically, so you wont need to configure each device individually. Linode is a decent option as their servers are fast, stable, and you'll effectively only pay for half your symmetric bandwidth as inbound is free.

good luck :(

Very interesting; is there a technical book (or chapter) or paper with a good overview of this comparative aspect of fly neurons?

I was just starting to look around to see what's available on comparative neuroscience in general, based on an interest in the most salient functional differences from human neurons, so anything related to that more general topic would also be welcome.

I used to work for a very large player in the adult online space, video content and the like.

Their research showed that customers who signed up had a window, measured in weeks, in which they'd blow a bunch of cash, then stop. This is why if you do sign up for an adult site you'll see their content, and ads for content from other sites (some they own, some their competitors). The links to competitors surprised me, but it makes sense. There's a very high Cost-Per-Action (CPA) in that space, and the window to get that user to spend money is closing, so any opportunity is worth looking into. You make less money sending them to your competitors, anything > 0.

 

In theory, if we can capture coherent pictures in the visible spectrum from many billions of light years away, we should be able to do the same with RF.

It's actually very easy to see why the opposite is true: stars famously broadcast a truly vast amount of power in the visible spectrum, which is what makes solar energy and photosynthesis effective.

Humans clearly do not have the power resources of the entire sun to use to power RF broadcasts. The total amount of power we have at our disposal from all sources is a tiny, tiny fraction of what the sun broadcasts.

And most of our power does not go into RF in the first place, it goes into transportation, manufacturing, etc.

So it's quite straightforward that there is no comparison between the brightness of stars in the visible spectrum versus the Earth in RF. Stars win hands down.

It isn't the technology, it's just the hardware.

Unfortunately, it is very much both. It's true that we can do better by building better listening arrays, and SETI has been continually doing that for many years, but there is also a problem of signal to noise ratio that gives a hard limit on sensitivity due to noise from terrestrial sources and from thermal and quantum noise in the receiving electronics.

Part of that could be improved by putting radio telescopes e.g. on the far side of the moon. The electronics issue simply needs better technology.

Yet the sky is not saturated with their communications. So therefor those civilizations must be using some other technology.

That seems logical, but that turns out not to be the case. A SETI scientist said in a talk (and I've seen this in articles since) that our deployed SETI listening technology is still nowhere near sensitive enough to pick up signals even from as close as the nearest star (Proxima Centauri, 4 light years away), if a planet there was broadcasting RF at current Earth levels.

(That doesn't mean SETI to date is pointless, because there's always a chance of a highly directional signal beamed our way, or of just something unexpected, like signals far far brighter than Earth's.)

So no, we have no idea whether the sky is saturated with radio waves or not.

It's behind Cloudflare, and they're leveraging other means to catch scraping. This hardly seems like "wide open"

"a bit much" is an idiomatic way in English of saying "possibly you shouldn't have been modded down so much for that statement" (because the first part of what you said is arguable, not an obvious troll, not obviously flamebait, not an obviously incorrect statement of fact).

I think that you being modded down to -1 is a bit much, but there is a problem here. What you said is potentially well and good for contexts that are purely utilitarian to the degree that anything but pure pragmatic functionality is to be viewed as an active negative, such as industrial control, power plants, etc.

But for most people's desktops, people expect both functionality *and* some degree of modern aesthetics, and there is an extremely common rejection of interfaces that look 15 years old, even if they were considered close to ideally functional and aesthetic 15 years ago.

Since that is demonstrably what the market generally wants, that is therefore the general trend over time: "flashy graphics" are sometimes overdone, but the word "flashy" is in the eye of the beholder, and most improvements to GUIs over the decades have been about modernization to meet the moving target of whatever "modern" means in each era, with actual breakthroughs in usability being far less common.

Furthermore, the people who design and implement GUIs are (with the exception of 1-person development teams) rarely the same team members who would address software vulnerabilities, so maybe that's where your -1 came from.

The fundamental problem seems to be the bottleneck of cars getting onto the highway. By creating a priority lane you'll be reducing the number of cars/minute that are able to leave via the regular lane. Additionally there will likely be some switching inefficiencies introduced with the new lane merge.

So some cars will get out faster, other cars will get out slower (as the non-priority cars wait for the priority cars to pass them and leave), I think we'll see average car wait time increase here. The extra labour used to manage entrance to the express lane could probably be better spent on highway flagging or looking to optimize the highway merge for more vehicles/minute.

There *is* such a thing as (write, execute), and this is what it is currently using, and people are complaining quite bitterly about it doing that, because it's a security weakness that is exploitable via buffer overflows etc.

Basically the fact that it allows for dynamic JIT compilation is exactly what people don't want the bad guys to be doing; potentially that turns a small bug into a complete take-over-the-machine exploit.

I'm afraid I was taking all that for granted in my original comment, which instead was about potential reasons why they might not have done something different as people are suggesting in hindsight.

I did mean that about time pressure, but I don't understand what you are suggesting.

The scenario is to suppose that they have some audio algorithm that is based on creating and executing a block of code a bunch of times, but for a very small fraction of a second, and then, critical assumption, it needs to create and execute a slightly different block of code, and so on, over and over.

Long ago I saw a demo of an Amiga video capture program that had precisely that sort of thing going on, where they could only get the throughput they needed by using self-modifying code, changing one instruction in an inner loop on a regular basis, and their approach held up under scrutiny of 100 developers critiquing them; it really was needed.

So I am sure that such things do arise in the real world; whether the current codebase truly has such a need, I don't know.

So *if* they have this need, then every time they create or modify a code block, they need it to be writable, but when they execute what they wrote, security issues insist that it it should go from (write,no-execute) to (no-write,execute), every single time.

Making that permissions change requires a system call every time, unavoidably.

Any scheme that allows avoiding that system call is inherently making different assumptions than I did above. Without knowledge of their algorithms, I don't see how we can be sure that assumptions like that are either right or wrong; I'm just pointing out that *if* they are correct, they explain why the codebase does what it does.

An alternative explanation that I tried to give a nod to is that they may have simply done a premature optimization that was not actually needed, but again, motivated as outlined above.