shimo5037
For something a bit more old school, I’d like to insert a shameless plug here that we open sourced something similar several years ago. It’s focused on the enterprise side, so setting it up is unfortunately quite a bit more involved. Screen rendering is obviously far less advanced as well, though still decent enough. It’s compatible with (almost) all Android versions since 2.3 which has its own fun challenges!
Anyway, great project with a modern take!
In the end, you tend to have a noticeable, vocal portion of users whom I'd generously call "social developers," who are bad at figuring things out by themselves and/or prefer asking things from another person to save a few minutes of their own time. Many of these users are very draining to deal with.
I'm also not sure why they bothered adding their basic UI in addition to the OpenWRT side, it barely exposes anything and it was common to receive error responses. Maybe they just felt like they had to add more funding goal rewards.
The antennas were a bit loose but the case is quite easy to open, so they were easily tightened.
I now have Ubiquiti gear and the DNS delays and other issues are completely gone. While I in principle fully support the project, it turns out that I just wasn't willing to spend days customizing the thing to get it to work at a reasonable level, especially when my own daily internet use relied on it.
If someone feels like the current retail price is a bit steep but wants to give it a go, I've got my silver 2GB RAM model available for a more reasonable price :) It has the potential to be great in the hands of the right person.
For example, even though I use SSH tunnels quite often, and can in fact remember the flags, I sometimes don't remember if the local or remote port came first. A minor issue for me perhaps, but I'm sure you can imagine someone getting stuck at some point, and having to bother a team mate to check what's going on, which is an entirely avoidable waste of time. You also have minor ops overhead for making sure the tunnel servers stay up and running.
In the end, aren't nearly all tech businesses about improving the user experience in some way? For example, you could set up your own mail server (and deal with the issues that come with it) instead of using Mailgun/Sendgrid, or take a taxi (or drive) instead of using Uber/Lyft.
Think of a front end developer working on a mobile site. Now, in an ideal world everyone would know how to set up an SSH tunnel, but let's be real here, even you probably have to look up the exact flags you're supposed to use every time you want to set up one. Combine this with the need for a publicly accessible server somewhere, and it should become somewhat clear that many simply do not possess the skills, resources, and/or couldn't be bothered to go through the trouble. With ngrok, you just download a single binary, make it executable, and you're ready to go. It's easy enough for most, although I suspect a GUI would further increase its reach.
Corporate policies often prevent employees from connecting their private phones to the internal network, so simply accessing the internal IP isn't really doable. You might be able to apply to have your device whitelisted, but that may take days, perhaps weeks, and even if you're approved, it doesn't really help as you cannot show your work to others (e.g. your team lead) without having their devices whitelisted as well. You might argue that everyone should have a company-provided phone with access to the network, and that's certainly a solution. Realistic? At most companies, probably not. You might have shared phones but who wants to work like that? Plus, there are developers who feel more comfortable playing with their own phones anyway. Regardless of which and whose device they have, they'd still be limited to WiFi only. Sure, you can emulate slower networks, but that's one more thing to know about. With a tunnel, you can see how the thing you're working on feels over a real 4G connection with no additional configuration. All this while developing locally with no need to waste time deploying to a separate environment.
That's just one use case where ngrok shines. The fact that you do not need to "correctly configure a firewall" is a selling point. Does it circumvent the firewall and expose machines on the internal network? Yes it does, and that's certainly a concern. But since people are people, perhaps you should have a similar, easy to use service available for your developers so that they don't have to resort to third party services you have no control over.
What would you suggest instead?
> Responsibility for Your Site > > 5. You will not engage in any promotional, marketing, or other advertising activities on behalf of us or our affiliates, or in connection with the Amazon Site or the Associates Program, that are not expressly permitted under the Associates Operating Agreement. For example, you will not engage in any promotional, marketing, or other advertising activities in any offline manner, including by using any of our or our affiliates’ trademarks or logos (including any Amazon Mark), any Content, or any Special Link in connection with an offline promotion or in any other offline manner (e.g., in any printed material, mailing, SMS, MMS, email or attachment to email, or other document, or any oral solicitation).
> (e) any Product purchased by a customer who is referred to an Amazon Site by a link that sends users indirectly to the Amazon Site via an intermediate site, without requiring the customer to click on a link or take some other affirmative action on that intermediate site (a “Redirecting Link”),
Since the user password is used as the DES key, and DES key size is limited to 56 bits (plus 8 parity bits), your key can only be up to 7 8-byte characters long. However, since ASCII only uses 7 bits, you give an 8 ASCII character key instead, and the unused 8th bit of every byte is simply discarded. If the password is shorter than 8 characters, it's just padded with zeroes.
Many VNC clients and sometimes even servers allow you to enter a longer password, but as long as they're connecting to a the standard auth implementation, they'll actually truncate your password to 8 characters during operation. Yes, even RealVNC's client does that when only the standard auth is possible. It will warn you that the connection is not encrypted, but it won't let you know that your password just got slashed.
Defining alternate authentication schemes is possible, but require VNC clients to add support for those. RealVNC has simply defined one of those. So everyone should just implement that right? I think you'll find out the reason why the standard auth is still so prevalent if you spend some time trying to find any implementation documentation for it.
To worsen the issue, Quay still doesn't seem to support parallel layer downloads, and Docker 1.9 even complains that "this image was pulled from a legacy registry. Important: This registry version will not be supported in future versions of docker."
I just ran a quick test (way off peak time) and Quay was 2.5x slower than Docker Hub for an image built from the same Dockerfile.
I'm looking forward to more usable international service at some point, but right now it just isn't really worth it.
With the big carriers here you pay 0.05yen per packet, where a packet is 128 bytes. For example, looking at my bill from March, I used 6,971,294 packets (0.84GB) which would have cost me a grand total of 348,564yen (~$3000). I "only" paid 5200yen (~$50) for it because I'm signed up for a fixed data plan like everyone else. The exorbitant base prices are only there to make sure that everyone signs up for the expensive plans without too many complaints.
Oh, and did I say that all three big carriers have the exact same prices with more or less the exact same plans? :)