If you hosted your own email server, why would you need to be familiar with SES, especially if you've been hosting longer than SES providers have been around?
Like email, I run my own HTTP server, serving directly to clients. I know about Cloudflare just from HN threads, but have never used it or know much about that whole reverse proxy universe beyond the very low-level details from having written several reverse proxies myself.
It's not that simple because it's asymmetric. The companies track you (via firms that can see your purchases across different retailers) but how can you track the companies to find a bargain? Historically you might follow Consumer Reports, your neighbor's advice, or just look at advertised prices, but if everybody is offered a personalized price, now it becomes more difficult for you to compare or even identify prices. And what you're offered today might not be--and if Amazon is any indicator, won't be--the price offered tomorrow, making it more difficult to plan and budget across purchases (individuals don't have the scale and analytic prowess retailers have).
Fair price discrimination would involve some kind of bidding system, but that has high transaction costs for both sides. And naturally sellers aren't interested in maximizing global efficiency or competitiveness. Like any company they prefer "solutions" that give them an advantage over the consumer.
It still might be a net win overall, and I don't have strong opinions one way or another beyond being apprehensive about knee jerk public policy proposals, but surely the sellers will see a larger share of the benefits, possibly accelerating wealth inequality and people's growing sense of economic insecurity. That sense of security is critical for maintaining free (or freer) markets, otherwise the population is prone to using their political powers to try to take back bargaining power, and very often that winds up being a loss for everybody.
They can't know, they infer. AFAIU, normally they just detain you at the airport and harass you to try to break you. To jail you they're technically supposed to be confident enough about you knowing the password to be able to charge you with a crime (presumably something like obstruction, possibly specific to immigration law, otherwise right against self-incrimination might prevent a conviction on failure to disclose alone), or have other evidence of some other crime. Then you end up in the legal system, where courts handle due process and a judge, preliminarily, and then a judge or jury decides if you knew the password.
Note that the recent high-profile case of a man being jailed involved him refusing to decrypt, rather than claiming he didn't know. He was deliberately trying to test the law regarding the permissible scope of inspection of digital data, to force the matter into the courts so the issues could be litigated in a controlled context untainted by other potential crimes; being arrested and charged was part of his plan.
AFAIU, the San Francisco peninsula (San Francisco + San Mateo counties) has one of the densest networks of ALPRs in the country. You can't drive more than a mile or two in the peninsula without passing an ALPR. And my educated guess is this is a response to the rise of property crimes, including car break-ins and theft, over the past 15 years, which became a huge political issue, locally and of course nationally. Those crimes began to drop precipitously after it became evident that criminals were being tracked and apprehended by the cameras, and I doubt it's a coincidence. IOW, at least in this region the cameras exit because of crime, and they're working.
That's not a defense of these wide ALPR networks, and certainly not a defense of how they're managed. But my point is that it's a thorny political issue because in many areas they actually work, at least to some significant degree. Whether or not they're worth the privacy cost, or whether or not alternatives would work sufficiently well, are fair questions, but precisely because they're fair and contentious questions means preventing their use won't be easy politically. Many of politicians and LEO officials pay lip service to privacy concerns, but behind the scenes they're wary of doing anything that would rollback the capabilities these systems provide.
[2026-10-01 9:35:10] % which make
/usr/bin/make
[2026-10-01 9:35:39] % /usr/bin/make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
A scholarly and far more rigorous argument against copyright and patents can be found in Against Intellectual Monopoly by economists
Michele Boldrin and David K. Levine. "We show through theory and example that intellectual monopoly is not necessary for innovation and as a practical matter is damaging to growth, prosperity and liberty."
Switzerland has ~440 people per paved road kilometer. The US has about ~80 people per paved road kilometer. That means Switzerland has more than 5x the number of tax payers to support each kilometer of paved road. Maybe Switzerland was smarter than the US in terms of not building infrastructure it can't adequately support, but in any event....
Why did you stop your comparison at number of people, instead of comparing the more obvious numbers like GDP vs population size? Number of people actually has no bearing on the ability to actually get things fixed.
I didn't want to guild the lily. Switzerland also has a significantly higher per capita GDP than the US. 1/4-1/3 higher.
Switzerland is just a really bad example to use because they're significantly wealthier than the US. The only other two non-city-states with a higher per capita GDP than the US are Ireland and Norway, but Ireland's is inflated because it's a tax haven (less real money available for public spending), and Norway's is inflated because of their oil and gas fields. Though, comparing the US to most any other country, especially individual European countries, is already specious. Switzerland is ~9 million, compared to ~340 million for the US. Scale matters, because of variance, selection bias, and the policy conclusions you can reasonably draw. A better apples-to-apples comparison would be between individual US states to individual European countries, or to compare the US to the EU as a whole[1]. People don't like to do that because such comparisons tend not come out the way they want. It would be interesting to read a follow-up comparing Colorado to Switzerland, not least because they're both mountainous regions. Not nearly as easy an analysis, though, because you'd have to figure out Colorado's share of Federal road infrastructure expenditures, plus Colorado-specific road data.
[1] To be fair, comparing the US to the EU can be a chore because many publicly available datasets, even from EU agencies, encompass not just the EU proper but larger geographic regions, or subregions of the EU. And of course Switzerland itself is just such an example as they're not a full member state. Like, try finding out the number of heat-related deaths. I couldn't find any numbers just for the EU proper. Some numbers included Russia, the Balkans, and/or Turkey, some were for subregions of the EU, and often it was a chore just to figure out which countries or regions were used in the report. It's a mess.
What if x is a register to toggle divide-by-zero exceptions? Normally this is none of the compilers business, but the whole point of volatile is a mechanism to express stuff like that, so it needs minimal semantics, e.g. no time traveling (compiler barrier), to be fit for purpose.
x being a register connected to the processor's division machinery doesn't speak to the fact that division isn't a language-defined visible effect, and so the implementation is not required to schedule it in a certain way in relation to the store to x.
Hmmmmm. It's late, but FWIW I think this comment from Martin from last year might be relevant: https://news.ycombinator.com/item?id=40838721 And I'm guessing the note that was added is fn#150 in C23. Volatile accesses aren't general memory barriers, but I think Martin's point is the potential for UB behavior means the compiler has to preserve the sequence order of the potentially UB operation relative to the volatile access.
The potential for undefined behavior means ... the potential for a situation to emerge where no further requirements apply.
If you regard undefined behavior as having ordering requirements, it's game over for optimization (not to mention the current understanding of undefined behavior). Any time you have bona fide observable effects near calculation, you are hamstrung, because the potential for UB is in every nook and cranny, around every corner.
I think it's perfectly fine for the division by zero to occur before the output is produced and flushed, in that example. The UB of a bad division can time travel because a division is assumed not to have UB and can be reordered before a visible effect to which it is not related (the effect doesn't require the result of the division, nor does the division require an output tied to the production of the visible effect).
What these people are looking for is a safe calculation mode in which a bad division does something that is well-defined, like raise an exception that can be caught. That is then deemed visible, and must not be reordered w.r.t. other visible effects. And while it does hamper optimization, it is a translation mode that can be enabled or disabled around a block of code. If the programmer is certain there is no bad division, or else don't care about that being ordered w.r.t. a visible effect, then they declare a low safety level. (Which, this still being C, could be the default level).
As long as C standardization thinking remains obtuse or hostile w.r.t. this type of programmer-controlled safety level concept, they will be forever confounded by dilemmas caused by wanting intuitive outcomes that logically require undefined behavior to be partially defined.
Both the C and C++ standardization committees have decided that even when there is undefined behavior the program is partially defined. But nobody is confounded by this.
Suppose we require it that the output flush must take place before the behavior becomes undefined by a bad division. That doesn't buy much because the visible effect is only that some bytes are passed from the stdout stream to the host environment. The undefined behavior is allowed to bring down that entire environment though; so our requirements don't add up to the certainty that the output has been transmitted out of that host system to some output device (display, serial or network, ...), or committed to durable storage. (The latter could be wiped out by the UB, even if so).
Basically, standardization groups should be dissolved long before they devolve into stuff like this, where they are just creating churn for the sake of their own continuation.
We don't need to suppose this, as this is what is already required in C. You are right that when I/O is performed it is up to the host system what happens, and it is also possible that on UB the whole system crashes if it is poor. But this is outside the jurisdiction of the C language.
What it is important though is that where C spec can be complemented by other specification that add reasonable requirements about the host system, e.g. that it does not crash then a program misbehaves or that I/O is performed according to certain rules, certain safety properties can then be ensured. This would not be possible without UB being restricted in this way. As compilers are now being fixed, this is not churn but a real world improvement people have asked for.
Almost all states offer pensions, or hybrid pensions and direct contribution plans. You have to add 1/3-1/2 or more (especially for states with retirement health plans) to yearly salary to appreciate real compensation.
It's not just a burden for the immediate parties. Having the ability to dispute rights and obligation going back indeterminate amounts of time adds risk to the rights and obligations of untold numbers of third-parties; everybody's interests become more interdependent and intertwined the more time has elapsed. One of the important functions of a legal system is to settle rights and obligations. Settled, transparent rights and obligations are also integral to notions of fairness and justice, so it's not a zero sum thing that statutes of limitations sacrifice fairness for cold transactional efficiency.
Like email, I run my own HTTP server, serving directly to clients. I know about Cloudflare just from HN threads, but have never used it or know much about that whole reverse proxy universe beyond the very low-level details from having written several reverse proxies myself.
reply