shimo5037's comments

Looks great. It certainly has become much easier to build such apps on modern Android :)

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!

https://github.com/openstf/stf

At first most of your users tend to be fairly advanced. After all, they've even managed to somehow find the obscure thing you've made. This is the most rewarding time for an open source project as many of the issues are real and the quality of bug reports and feedback is extremely high. Over time, as the project gains popularity, many of these issues will either have been solved, or have become easily googlable. Therefore you'll rarely hear from the advanced, intelligent portion of your users, although it's also certainly possible that they've already moved on to shinier things.

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.

This matches my experience. Even now, depending on the day, I might be looking at around 30-50 emails of varying, usually depressingly low quality per day. I've had some relatively successful one man projects in the past and at peak popularity it would take me several hours per day to sift through everything.

It's good to hear that at least some others have not had any issues :) It is certainly possible that the ISP modem may have been doing something special, but I've now been through at least 4 different routers of various grades over the years and sadly Omnia was the only one to ever exhibit that issue here. Or it may have had something to do with IPv6 or PPPoE. Hardwiring DNS to 8.8.8.8 did not help either. In the end I deemed it not worth it to waste any more time attempting to fix it.

I have one and I'm not using it anymore. It's quite possible that the software is more mature and usable now, but unfortunately it just wasn't good enough at the time. There were severe issues with DNS, with most requests taking a few seconds to complete, making simple tasks like browsing the internet quite infuriating. By default, there was no support for resolving local hostnames either, but it was possible to make that work by modifying some of the config-generating scripts to add a forward to another local DNS resolver. I don't recall the details exactly but there were at least two local DNS resolvers running due to missing DNSSEC support in one, and it may have been possible to enable a third resolver as well. Quite confusing.

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.

As a side note, many Chinese brands have started preventing applications from starting automatically without being whitelisted in settings (different for each vendor). Examples include Xiaomi (since MIUI 8.1 or 8.2), and some recent ASUS/Lenovo devices.

I'm not sure how you've interpreted the post that way. The point of that one specific thing was nothing more than to bring attention to the fact that even users who do have the skills to do this all by themselves often can't recall how exactly to get it all going without googling or reading manpages a bit, and that people who are less familiar with these things would be even less likely to know how to set up an SSH tunnel properly, or perhaps even know about them.

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.

I don't think you're the target audience.

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.

I believe the reason they continue selling them is so that companies with existing deployments can expand them with the same gear that already works for them. It's the same for most enterprise-oriented hardware.

What would you suggest instead?

You must not have been looking very hard. Searching for "email" on the policy page gives you:

> 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).

Unless the user takes a concrete action to confirm the redirect, that is not allowed. Under Disqualified Purchases:

> (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”),

It can be slightly more complex than that if you use a package manager to publish your work. I once accidentally leaked a password due to having both a .gitignore and an .npmignore, and forgetting to include my .env file in the latter. Fortunately, I realized what had happened almost immediately and was able to change the password. Now I tend to `tar tf` everything before publishing.

Not sure if you're being sarcastic (there's the non-Nexus Android experience after all), but I did a fresh install of Windows 10 Pro on my gaming machine a while ago. Full retail license and an official .iso downloaded from Microsoft. There's barely anything installed on that machine, however I was also surprised to find Candy Crush in my start menu after a while. It's probably just a shortcut to the store, but it does look quite a bit like it's already installed.

While it may have worked in the past (for a while anyway), what exactly prevents spammers from stripping the suffix, given that the functionality has been public knowledge for many years? Best case they'll be lazy and try both with and without, and you'll end up knowing. Blocking the alias cannot possibly have any effect.

They're actually made by HTC. Would be interesting to know what their exact arrangement is.

The name of the project means "ugly" in Finnish. I wouldn't sweat it though, no one cares. Just thought I'd let you know since it's mildly humorous.

Honestly I'm not sure why they'd say that. Huawei's build quality is extremely good, especially in the Mate line of products. I would have positive expectations until proven otherwise.

Having had to implement VNC authentication a while back, I can assure you that it is not agnostic, and you have inadvertently revealed the reason for that in your own post.

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.

Same. Definitely doable. It did take me a guesstimated 1.5h though.

Please don't use Quay for official open source images if you care about international users, or at least offer a Docker Hub option as well. Quay is super slow compared to Docker Hub. When I contacted support back in July, they were very polite and professional, but in the end "everything is being served from AWS's US East region". Peak time performance is intolerable. It was so bad that our systemd units were timing out even with a massive 5min TimeoutStartSec.

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.