71–80 of 89 posts
A nice to have but relatively unimportant feature suggestion, the option to filter by total capacity independently of drive type. That aside, this will be useful for figuring out hosting for side projects, thank you for sharing!
Earlier quoted context omitted.
What was interesting to me is the search ID, https://www.serverhunter.com/?search=157-857-0B2 for example. Each change results in a new search ID. If you toggle the same option on and off, the search ID is different every time. I originally thought it was a way to reference a unique combination of the facets but it seems to create a new search session for each query.
The search ID is indeed unique, it's a reference to our database which stores your filters, sort order, and column selections. We might replace it with something that doesn't require the backend at all, but the URLs will end up quite long if you have a few filters selected. For now, we figured a short URL is nicer to share with other people. :)
Earlier quoted context omitted.
If you distinguish broken and non-broken IPv4, maybe you should also distinguish broken and non-broken IPv6? Currently, it's impossible to distinguish offers with a proper /48 from broken crap with a single /64 or even less, which makes the comparison mostly useless for me, as there is a lot of broken crap in that market to wade through.
Since IPv4 space is starting to become a significant cost, they make up a large percentage of the price for the cheapest VPSs. This is why some providers have started offering NAT VPSs - ideal for backups, monitoring, etc. Since NAT IPv4 is not the norm, this is something they clearly advertise on their website, and hence something we can easily distinguish. With IPv6, the information from the provider is usually lim…
Though I think there is a more important thing to note here: Maybe you should explicitly support handling of unknown values in the UI? Failure to do so is IMO one of the biggest problems of most specialized search sites.
Sure, there are attributes that cannot always be determined reliably if at all--but instead of either ignoring the attribute completely or forcing it to "false" or "true", or some other explicit value, why not allow the user to specify whether entries for which the attribute is unknown should be shown? That way, if my requirement is proper IPv6 support, for example, I can decide whether I am in the mood to wade through tons of crap, but still have you filter out all entries for which it is known that proper IPv6 is not supported, or whether I want to ignore those and only look at the (probably more expensive) selection of providers that clearly advertise that their product isn't broken.
Earlier quoted context omitted.
The search ID is indeed unique, it's a reference to our database which stores your filters, sort order, and column selections. We might replace it with something that doesn't require the backend at all, but the URLs will end up quite long if you have a few filters selected. For now, we figured a short URL is nicer to share with other people. :)
Well, a URL that stays valid would be more important than a short URL? I am assuming that you do garbage collect your DB?
Earlier quoted context omitted.
Since IPv4 space is starting to become a significant cost, they make up a large percentage of the price for the cheapest VPSs. This is why some providers have started offering NAT VPSs - ideal for backups, monitoring, etc. Since NAT IPv4 is not the norm, this is something they clearly advertise on their website, and hence something we can easily distinguish. With IPv6, the information from the provider is usually lim…
Well, I see the problem, but then, a search site that doesn't allow you to use effective filters is ... kinda useless? Though I think there is a more important thing to note here: Maybe you should explicitly support handling of unknown values in the UI? Failure to do so is IMO one of the biggest problems of most specialized search sites. Sure, there are attributes that cannot always be determined reliably if at all--…
Right now we do support unknown attributes, they show up unless explicitly filtered out. For example, a server might have an unknown CPU speed, in which case it will show up in the results unless a CPU speed filter is applied.
Just to make sure we're on the same page, you'd like to see the size of the IPv6 range assigned to the server, correct? Is there any more information you'd like about the IPv6 support?
Thanks again for your feedback. :)
Most VPS hosters "share" CPU time between users on a host server (Which mean CPU type/speed doesn't mean much). So it would be great if you could filter for that on serverhunter to paint a fair(er) picture, because a few hosters give dedicated cores by default. When we tried benchmarks on the Hetzner Cloud we found that some servers had as low as 10% max CPU on a crowded host server, which makes sense as to why they…
Most VPS hosters "share" CPU time between users on a host server (Which mean CPU type/speed doesn't mean much). So it would be great if you could filter for that on serverhunter to paint a fair(er) picture, because a few hosters give dedicated cores by default. When we tried benchmarks on the Hetzner Cloud we found that some servers had as low as 10% max CPU on a crowded host server, which makes sense as to why they…
Earlier quoted context omitted.
Well, I see the problem, but then, a search site that doesn't allow you to use effective filters is ... kinda useless? Though I think there is a more important thing to note here: Maybe you should explicitly support handling of unknown values in the UI? Failure to do so is IMO one of the biggest problems of most specialized search sites. Sure, there are attributes that cannot always be determined reliably if at all--…
I understand what you're saying, but for the vast majority of people, just knowing whether it has IPv6 available or not is enough information. We do have to strike the right balance with the UI between power users like yourselves and people less familiar with hosting. Right now we do support unknown attributes, they show up unless explicitly filtered out. For example, a server might have an unknown CPU speed, in whic…
Well, that's somewhat of a chicken and egg problem, though. It's not like those broken networks are actually necessarily good enough for the purpose that people use them for, it's just that noone is even aware that the network setup is broken and that that is the problem they should be fixing.
> Right now we do support unknown attributes, they show up unless explicitly filtered out. For example, a server might have an unknown CPU speed, in which case it will show up in the results unless a CPU speed filter is applied.
That's exactly what I think is broken, in that unknown values are not handled explicitly in the UI, but forced to an explicit value. When I specify "I need at least 2 GHz", say, that says nothing about whether I want to see servers for which you don't know the CPU speed, as such a server very well might have a 5 GHz CPU. All it says is that I don't want to see servers for which you know that the speed is less than 2 GHz. So, you shouldn't make assumptions about whether I want to see those servers, but rather let me choose what to do with them.
Now, I don't know whether this is important for clock speed, but often there are cases where there is a particular attribute that is known for many products to have a value that doesn't fit my needs, so it would be great if you could say "not any products where this attribute has value X" ... except that suddenly half of the remaining candidates vanish, too, because that attribute happens to be unknown for those, which then means you have to do all the filtering by hand after all, instead of using the search/comparison site to weed out 90% of the candidates and then investigating the remaining 10% by hand.
> Just to make sure we're on the same page, you'd like to see the size of the IPv6 range assigned to the server, correct? Is there any more information you'd like about the IPv6 support?
Well, yes, prefix length (or number of addresses for offers that don't even have a prefix, I guess), and I guess whether that prefix can be routed completely to the server, as that is, as ryanlol noted, something many hosters fail to do correctly as well. If you can figure it out (or for providers that are willing to feed you machine-readable data), it would also be useful to know whether the reverse zone of the IPv6 prefix can be delegated.