It looks like the page it was supposed to link to is no-longer there (which was a google app-engine app if I recall correctly) but maybe someone with some better google-cache fu can pull it up.
I have a set of scripts that I've compacted into a one-click binary that spin up new AWS instances as a VPN. Would people buy this? (I'm planning on a Show HN: in a week or two, once I get the final debugging and product artwork done.) Even then, I'm really not sure if there is an advantage in having you're own home-grown VPN or using a service like StrongVPN (or any of the other "google: private vpn service" VPN service providers)?
I'd like to think that people would want to "run" their own, but I'm wondering if most even would care.
An AWS is about US 10 per month ? So that is rather expensive compared to the online services. The online services have you choose very easily between different countries. A bit more difficult / limited with AWS ?
Will the 'login' ip address always stay the same in your setup ? (I mean in case I stop the remote machine and later start it again).
On the upside: AWS is probably more secure (no man in the middle possible) and maybe faster ?
First you should make a good description of those 'people' who want to run their own vpn. What are their reasons.
Thanks for the suggestion on the description. That should help in preventing me from conflating the different use-cases of running a VPN. For example: viewing a US Netflix account while in India vs. At public coffee shop vs. Protect myself and my family from persecution.
The login would change as you bring up and down servers. You get a new fresh install of the service on an instance each time you start a new one up. (Although the option to start and stop could be easily implemented.)
You can choose between all of the AWS Cities/Countries that AWS offers which is 9 across Asia, Australia, Europe, The USA and South America. Which hopefully would provide a good mix for a while.
As for expense, this is where the different use cases come in. If you want to secure a coffeeshop connection for a few hours then you'd just pay a few cents for the protection, which I think is reasonable. But if you want a more permanent connection then I may need to think more about the costs, or starting and stoping servers automagically to save costs.
Can some one answer this question. It says that Go1.4 will be needed to compile Go1.5. Does this mean that Go1.4 will always be needed, even for Go1.6 and beyond? So are they essentially locking things to the Go1.4 "C" code, then updating on top of that?
Right, but if someone surreptitiously deleted all Go compiler binaries from the world, then we'd have to go back to compiling the C source of 1.4...
Of course, that's the nature of bootstrapping! If someone managed to erase all the software from all the computers in the world, we'd have to go back and find an "Old world" Mac and use the on-die Forth compiler to write a C compiler so we could start compiling things again.
Provided people didn't forget. Recreating from memory will take a fraction of the time. I would go for a lisp interpreter in assembly then implement a c compiler in that.
Yes. It means that anytime you want to add a new supported architecture, you'll need to bootstrap through Go 1.4.
Otherwise, I'm guessing that for Go 1.6, they'll rely on you having a binary distribution of 1.5 (probably from your distribution, or their website), etc.
>It means that anytime you want to add a new supported architecture, you'll need to bootstrap through Go 1.4.
That's not true at all, (1) you write the backend for the target machine, (2) you recompile the compiler with the new backend included on a supported host, (3) then use the new compiler to compile itself for the target using the new backend, (4) you now have a compiler that runs on the target.
Same process is used to port C compilers (or any self-hosting compiler, really).
Yeah, I've thought of this too. I was thinking you could just use a normal mobile network, as you'll just be sending the correct color to a full screen (not a ton of data needed for that). I was thinking that a website serving up web socket connections would be the best way to send the data, no clock sync needed.
Just spin up $10K worth of AWS instances for a few hours to handle all of the connections, and done.
clock sync is far easier than sending data. Once the clocks are in sync the demo just runs. If you think the clocks are going to drift just sync them every 10 to 20 second.
Example: This demo runs on clock sync. In general no data is sent between the machines. They are running independently. They just happen to be using the same clock.
I think this is a good idea. There can be a change in the structure of where things are hosted (think moving the images to a CDN as traffic increases) which won't require a new client to find the optimized images.
I agree that it's the overhead carry-ons that cause most of the problems. From
1. people wanting to make sure they get space.
2. People incorrectly placing their luggage taking up more space than needed in a bin.
The solution:
Carry-on Valet. Have 3-10 airplane employees (indoor luggage handlers) load the carry-on's to the bin above the seat number the person will be sitting in then leave the plane from the back. (For more speed have people start loading as the bins are filled from front to back)
I think large international flights could be excluded.
The airline would need to only have a few more luggage handlers to do this; as they are already at the gate, just outside, right?
One thing that your recipe format helps with is timing, which is one of the things that I always found fun about cooking. Which is, how to have everything work to come out about the same time. So how do you prep and cook, and work in a special detail at the same time.
Do you have plans to incorporate full meals on the site, such as a meat dish with two sides and how to cook them all together, to come out at the same time?
It looks like the page it was supposed to link to is no-longer there (which was a google app-engine app if I recall correctly) but maybe someone with some better google-cache fu can pull it up.