Definitely ran into "Alpine Linux can cause unexpected runtime bugs" -- with strftime, libc and musl don't have 100% equivalence of the date/time formatting strings.
Last mile fixed lines are outrageously expensive compared to wireless infrastructure, with the result being that many countries with limited land lines have wireless infrastructure other, more industrialized countries can only dream about.
To put it this way: I had more reliable coverage and lots more bandwidth available just outside Mogadishu than I've ever had in San Francisco.
You'll find most U.S. urban areas are just as connected as San Francisco. SF NIMBY mindset prevents infrastructure improvements required to improve connectivity.
Paris isn’t particularly high density, and practically everything is historical, but you don’t see big ugly base stations everywhere to provide excellent coverage.
And their telecom (wired and wireless) rates are dirt cheap.
I can vouch for this. Currently, living in Chennai and we have 1Gbps connection for 2000INR per month where as in my native you'll get 24Mbps for the same amount.
I hate to be a Debby downer, but I'm constantly unsure if I'm happy with Google being able to read my emails, let alone a random company out of nowhere.
It's unfortunate, because there is a huge opportunity for cool things to come out of handing your email over to some company (including this app I'm sure) but the risk right now is just too great.
Hmm. Unroll.me is owned by Slice, I wonder if Slice has a different policy regarding selling aggregate user data (since it also scans your inbox, but to find shipping and delivery emails).
The subsections "Vendors and Suppliers" and "Anonymous Use and Sharing" on section V "How we share your information" are quite vague ...
If you're going to charge me a subscription instead of mining and selling (even abstract insights), I'm game. But first you have to promise you'll never mine and sell my inbox.
When we ask for you to say "we will never mine and sell your inbox" and you instead say "mining and selling your inbox data isn't our business strategy," I hope you understand why that would make people nervous about using your product.
I think what is making people nervous would be something like this phrase from your privacy policy:
>We may collect other information that cannot be readily used to identify you, such as (for example) your Email Meta Data and IP address of your computer.
You make clear earlier that you will not sell or rent personally identifiable information:
>If you do provide personally identifiable information to us, either directly or through a reseller or other business partner, we will: not sell or rent it to a third party without your permission
But it is unclear what "email meta data" means and whether or not you will rent or sell anonymized data "that cannot be readily used to identify you". Other questions might include how long you store this information.
With all due respect "mining and selling your Inbox data isn't our business strategy" is not the same as "we will never ever ever ever sell or mine your Inbox data". My inbox is too precious for any potential loopholes.
Yeah, I understand collecting data is a part of training your model but it could be worth explicitly saying that zero data (either personally identifiable or anonymized meta data or any data at all) will be sold or rented. And if a change to that policy happens, include in the language of the user agreement that it isn't retroactive and only applies to new accounts.
The vague language is what bothers people. Probably having very strong language in the opposite direction (that you will NEVER sell any data, and would shut down rather than sell it) would probably win you favor.
Mubadala is Abu Dhabi's sovereign development company; its "mandate is to facilitate the diversification of Abu Dhabi’s economy" [1]. The SoftBank Vision Fund is "managed in the United Kingdom by a subsidiary of" SoftBank Group Corp [2].
Saudi Arabia's "Public Investment Fund was established in 1971 to provide financing support for projects of strategic significance to the national economy" [2]. It is the Saudi analog to Abu Dhabi's Mubadala. PIF is an LP in the SoftBank Vision Fund, albeit a significant and likely influential one.
And you can get an awesome T-Shirt if you complete it. I wear mine with pride, mainly because in the process of doing it, I nagged our business ISP into properly supporting reverse delegations
I'm kinda sick of all the AWS posts on here, but I'm trying to be fair since some of them are really interesting.
This is one of those that's more of a "about damn time," features that'd I'd care about if I already didn't go with Digital Ocean/Linode instead just because of IPv6 support.
The reason there are all these posts in the last few days is because AWS's conference re:Invent is going right now in Las Vegas, and a lot of these announcements are therefore being made right now.
This is the post I've been waiting for 2+ years - we have a ton of projects that we would like to deploy on AWS, but EC2 and friends have never supported IPv6, which has blocked us from moving forward, and our customers are reluctant to deploy on anything other than the big 4 (IBM/Google/Azure/AWS).
I think "about damn time", but I definitely want these posts - I use AWS despite its flaws, and it's important to me to know what's going on.
As long as AWS is both widely used by existing users, and is a likely option for new users evaluating alternatives, these AWS posts are always relevant on HN.
We needed IPv6 support five years ago. IPv6 is so vital because without it, we'll see the cost of public IPs skyrocket. I'm surprised it hasn't considering two of the places I worked for in the past few years had trouble purchasing IPs for some of their larger data centre offerings.
It's sorta like the network neutrality argument, except you're talking about limits on who can offer services to everyone vs those with newer IPv6 devices and ISPs. You can end up with two different Internets.
What product are you building where you can avoid needing public IPv4 addresses considering that the vast majority of the people on the internet still use IPv4? It seems like you'll still need both for many years.
Yes, I agree with you. Which again makes me wonder why djsumdog considers full IPv6 support so critical. Except for very unusual businesses it doesn't seem to make sense.
Our entire application back end is written in IPv6 only. We don't have an IPv4 version of our product. Until IPv6 was offered, no way for us to host our application on AWS.
Good question - It's not the APIs that are the issue, it's the actual IPv6 addresses in the packets on the wire that we need. All of our remote devices (typically on the order of 5 million+ for larger customers) have IPv6 addresses. We can use tunnel routers to get the traffic over IPv4 networks to the destination, but the applications themselves are addressing the devices with IPv6 addresses - which means, at least on the network segments that our many applications servers are running on, we need to have IPv6 routing working.
Everything we've done assumes an IPv6 network - trying to squish large device networks into IPv4 is just a losing battle for a huge number of reasons (address mobility, address conflict, large number of downstream devices (20,000+) per network segment, etc...)
Couple different classes of customers - utilities are the existing (Electric/Gas/Water meters) and IoT (Sensors, Street Lights, Parking) are the up and coming.
Both of them lend themselves well to mesh networking application, and mesh networks, in which any one of the 5mm+ deployed devices might appear in any one of the 10,000+ network segments, and in which we just want to concatenate the MAC address and Network segment to get a network address (basically SLAAC) - really makes IPv6 a pretty good fit.
A few months ago Apple made it a requirement for all new iOS apps and app updates to support IPv6 only networking.
If the app backend is not also available from a network where IPv4 is completely blocked, the app is rejected.
At the same time, AWS does not let new accounts to create EC2 instances outside of VPC, and only provided IPv6 support in the non-VPC classic stack (only available to old AWS accounts that signed up years ago).
So for the last few months, AWS has been unusable as a backend for iOS apps unless you have an old classic AWS account.
The requirement is only to work in networks with NAT64. That means your app can not hardcode IPv4 addresses and not rely on IPv4 only APIs, it has to work if any of its backend services are only visible through an IPv6 address from a NAT64 gateway and it receives that address from a DNS64 service. The backend service itself does not have to have IPv6 connectivity.
A funny quip, but since it seems like you're missing the point: what's the business impact of the choice, or the existence/absence of IPv6 support in a hosting provider?
If I'm running a small startup that's available as a website, how does IPv6 support matter to me? (Assuming that I can otherwise get IPv4 addresses for hosting my site, which I can.)
Because there are many other factors in choosing a hosting provider (price, performance, features, security, scalability, etc). It seems a bit weird that all of these would be less important to someone than IPv6. Though I guess I can imagine that for some businesses it could be hugely important. Was just wondering what OPs business was that it became an overriding priority.
Rolling out an IPv4 only stack right now is debt. IPv6 has finally hit the point where there's no longer an if portion to the question, but rather a when. Every server rolled out in an IPv4 only setup, every service built, etc, is one more potentially service-interrupting area that will have to be changed when port your stack to IPv6. If you're young and small, starting as IPv6 native means that the next few years you'll have an advantage over your competitors because they'll be thinking migrations while you're thinking about growing your business.
That's reasonable, but I think you significantly underestimate how long it will take before these sorts of conversions will become necessary. IPv6 is 20 years old. These things take decades not years.
In addition, I think you overestimate the difficulty of conversion. Most backend servers run on 10.x.x.x networks and that doesn't need to change. You just need a proxy in front of them that can speak IPv6. Installing a new proxy does not sound like a hard job. It sounds trivial.
Great! Lots of people on Hacker News use AWS because places like Linode and DO don't actually have all the services and scale their work requires. Believe me, we agree that this announcement is several years overdue. I think most engineers who work in AWS would also agree. But when you get to their scale, it's hard to make big changes like this in a safe way. The fact that it rolled out in a brand-new region (us-east-2 only for now) is good evidence that they are being very very careful with this rollout.
And as mentioned, the reason there are so many AWS posts this week is because they save up all their announcements for the conference going on right now. I sorta wish they'd spread the stuff out more, myself, but these are mostly HN-front-page quality announcements. It's just a year's worth of work dumped all in two days.
>But when you get to their scale, it's hard to make big changes like this in a safe way
Which only makes it more baffling that AWS still doesn't support IPv6 everywhere.
IPv6 is 8 years older than AWS. AWS is a decade old. Given that the inevitability of IPv6 is long known and that it's well known that as a rule changes get more difficult the bigger you get, I would have expected Amazon to start IPv6 deployment much earlier, back when AWS was much smaller.
