ericyan

It also runs on iOS/iPadOS and Webkit is the only allowed engine on these platforms (outside Japan).

The status page has been updated. PR and webhook statused red and now listed as "Incident".

(Disclosure: GitHub employee)

I see, so you are using PaaS and I was talking about IaaS offerings. The term cloud is so vaguely defined that it can mean so many things.

If the PaaS works for your scale and budget then it’s perfectly fine. I just want to mention that it is probably no longer the case for scaled-ups.

The business case is that someone else is doing the infrastructure management for you.

Many business people believe that moving to cloud can reduce the headcount needed for managing the infra, but that is usually not what's happening. You will still need more or less the same amount of people to patch the OS and configure the networking, but with a slightly different skill set -- instead of Cisco IOS commands, they now need to deal with AWS transit gateway.

Every data center I worked with offers on-site remote hands that will rack new servers or replace hard drives or PSUs for you. There are also third-party companies that offers this service. Redundant power and air conditioning are the responsibility of the colocation provider and those are covered by the SLA. Those data centres do have generators on-site.

That said, configuring you top-of-rack switch is usually not covered by the co-location contract. This need to be done by a network engineer, usually the same person that would manage VPCs.

Previous discussions when they relicensed Grafana, Loki, and Tempo to AGPL back in 2021: https://news.ycombinator.com/item?id=26877528

RFC 7766 [1] actually requires TCP support:

Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS implementations MUST support both UDP and TCP transport.

For stub resolvers like the ones provided by glibc and musl:

Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.

[1] https://datatracker.ietf.org/doc/html/rfc7766#section-5

A market has two sides: supply and demand. The assumptions only involves the supply side but we do not know much about demand, so would be hard to give a full picture of how the market would look like.

That's said, if we have ample supply of any given commodity/occupation, then the market will greatly shaped by what the demands look like.

We should have a linter for issue/PR comments that flag out sentences starting with “You are...”. The scope of the comments should be limited to the issue or code and must never extend to the person that bring it up.

Looks like their database choked due to the load: https://github.blog/2022-03-23-an-update-on-recent-service-d... With a single primary taking all the writes for that cluster, it would be tricky to tackle this. #hugops

You might have uploaded your name and face willingly to Facebook in order to set up your profile, but without proper safeguards and legislation, the data might be used to train an AI model to use your face to identify your relations with other user using photos, which they also willingly upload, to power features such as people you might know and of course, advertising. The data might also be sold or transferred to third-parities like Cambridge Analytica for political advertising or government agencies for "national security" -- all without your explicit consent.

It is true that it does not matter if a piece of data is stored in either side of the Atlantic, but this is not a engineering problem about data locality and latency. As someone who spent months working on a global distributed GDPR-compliance identity store, my life will be much easier if the problem can simply be solved by paying a slightly higher inter-region data transfer fee.

Unfortunately, US and EU here are not referring to cloud regions, but as jurisdictions because different laws on data protection apply. None of us likes this kind of complexity, but "power move" would be an overly-simplified abstraction of this problem.

If I have to guess, it probably have something to do with the the migration to MasterCard Debit from Maestro.

I only said this "proxy" need to be dual-stacked. This "proxy" or "gateway" or whatever refers to the public facing part of the their stack -- if they don't have a public facing part then they don't have this problem.

The "proxy" can outsourced or manged on-perm and does not have to be shared with anyone. This "proxy" may or may not be a L7 proxy that only understands HTTP.

I run my own proxy for HTTP(S), SSH, SMTP and DNS. It took me about 1 hr to set it up. Only 4 IPv4 address are used for my whole stack, the rest are all IPv6-only.

This would make sense if (and only if) all other things are equal. In reality it is slightly more complicated than that.

The second-largest chain, Jumbo, will happily accept my AMEX credit card. In many cases, the groceries are even (slightly) cheaper there. That's why it has been my preferred place to do the groceries for years. But I find my self goes to ah much more often than Jumbo recently, simply because I moved and there is one right across the street.

As a general rule, ah (and bol.com) do not accept credit cards (or debit cards that need to go through the credit card network). This can be independently verified on Google Maps if you look for those 1-star reviews.

There are a small handful ah branches (see below) in tourist spots that does accept credit cards. In all other places, you should see posters apparently made by the staff that puts red crosses on Visa, MasterCard and AMEX logos near the entrance and/or the checkout kassa.

From https://www.ah.nl/klantenservice/onze-winkels/zelfscannen-en... (in Dutch):

In sommige winkels kan je met je creditcard of buitenlandse pre-paid debetkaart betalen: de winkels op Schiphol, veel stationswinkels, de winkel achter het paleis op de Dam in Amsterdam en de winkel aan de Weteringschans in Amsterdam. Bij alle andere winkels kan dit niet.

Yeah, the catch is "if a merchant accepts..."

I live in the Netherlands and biggest supermarket chain here, Albert Heijn, is strictly Mastro-only. This is not a problem for the locals, but you will find angry reviews left by tourists on pretty much every ah branch in Amsterdam on Google Maps.

if your users don't have IPv6 (and many don't), you're basically screwed

Not quite, all you need is to make sure the proxy/CDN is dual stack, like what this IPv6-only hosting service did: https://www.mythic-beasts.com/order/rpi/

Cloudflare, for example, does this for free: https://community.cloudflare.com/t/proxy-ipv4-visitors-to-ip...

This practise is illegal in the UK and that's probably why they decided to this instead

I am also skeptical about their claim for taking care of tax management.

I had contacted Paddle for UK VAT invoice for our Setapp for Teams subscription and their incompetence is phenomenon: first they used an EU VAT number (this is post-Brexit), then they fixed the VAT number but the amounts are in the wrong currency, one of the support agents even get my name wrong once...

Most importantly, I should not even have to ask for a VAT invoice in the first place.

Frank W is the man. He did a much better job than SinoVOIP staff would.

Wiki: https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:start

Kernel: https://github.com/frank-w/BPI-R2-4.14

OpenBSD runs on Edgerouter

I think the OS is a fork of Vyatta, so it should be Linux.

I also own the original R2 board and the best doc I have found so far is actually not the official wiki, but the one created by Frank W: https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:start

I was hoping that I can built my own router with it, but so far it is still a learning process. Although, it is still fun.

I would say economics is more like historical studies. It is not trying to predict anything, it just give you some tools to learn from the past.

It is not supposed to be a crystal ball that you can see thought the future. Actually, I am not sure if such thing actually exists, but probably a physicist can prove that.

Your are right about your last point as in real world there is no such thing as inelastic demand.

Food definitely is not as in that case there will be no need to pour the milk into the river during the Great Depression. Basic medication such NSAID are cheap because there's no patent and can be mass produced and things like Novartis’ Zolgensma is apparently a different story. For electricity, don't get me started with Texas... I agree it probably a problem that is it is not controlled there.

The point is, yes there will be more variables in the real world, but the most basic rules still applies.

I am not sure if indicating anyone lack of basic understanding of economics counts a personal attack, but calling people as assholes surely is.

Since you talked about PPEs, you can check what happened in Wuhan during the first outbreak. The Chinese government demands no price increase for PPEs such as face masks... and what happened? The hospitals asked the public for donation of N95 facemasks because they cannot get those from the market. Every one in China are of course entitled for protecting themselves, but the truth is, at that time supply is simply not enough for the whole population and medical workers who needed those most cannot get them even the hospitals have enough dry powder to pay up. The market was awfully inefficient at that time.

Having every single mask strapped to a face and zero masks in a warehouse is far from enough. In a shortage, you need MORE facemasks. You need to make sure there will be enough are being supplied at the market. With a pricing cap, there will be no incentive for putting stock in the warehouse on sale and producing more, and it makes things worse.

You need to revisit Economics 101. High demand -> price rise -> more supply -> price drop. If you set a price ceiling, this will make the shortage worse as the market cannot properly function.

Based on what I learnt from my economics class back in the day, rent control is never supposed to work. A ceiling on rents would reduce the supply and eventually the quality of housing available will also drop.

Rent control is usually a vote-winner, but vast majority of economists would also agree that it is a bad policy.

They are just not going to drop this idea, aren't they? Google is in the online advertising business after all.

You also need to be aware that in this case, the attacker is/would not targeting any specific device. For brute forcing, all it takes is a dictionary of most common passwords and a list of devices that are exposed. Attackers won't spend too much time on any single device as there are so many options out there.

Well, real people won't choose any random 10 characters as a CSPRNG would do. Even when picking words from a dictionary, instead of four words, most people would probably just use one (or maybe two). For those are more inclined, they might mess with the capitalisation and sprinkle some numbers to make it "more secure" and adhere to certain password policies. This does not really contribute to the odds as you might expect.

Anyway, the point is, people are terrible at generating (and remembering) secure passwords. By ruling out the default password just means it is not going to be the most insecure one, but the chances of the custom password being secure is still pretty low.

These routers all have secured passwords that are non-default.

Secure passwords is just a tiny subset of non-default passwords. Chances of an average human being being able to come up with a password with enough entropy to be called as secure is pretty low.

These routers were deliberately placed on the internet by people that knew enough about them to do so.

This means these people knows how to expose the management interface to the internet. It does not mean these people have enough knowledge on securing their devices -- based on their actions, it is more likely that the opposite is true.