One of my main reasons for staying with Firefox is that in the long term, I think it's good to have a diversity in browser engines.
Back when I started web development, there were standards, but nearly everybody just coded to what Internet Explorer supported. Which I really hated :-)
In the past few years, I've seen the occasional "works best with Chrome" website, which worries me, but so far it hasn't been too bad.
But if we as a community leave the browser market to Chrome and browsers with engines of similar origin as Chrome's, we'll get back to the bad old days.
> In the past few years, I've seen the occasional "works best with Chrome" website, which worries me, but so far it hasn't been too bad.
Microphone & webcam support, screensharing and stuff like that almost always shit the bed for me. Slack, teams, they don't care to check if their shit works on firefox.
As Chrome has slowly become the default browser in enterprise environments it makes sense to cater for the _paying_ customers of Slack, Teams, Jira, etc. and they become the focus of product development.
It didn't feel that long ago when Internet Explorer was the primary target for development.
FHE might allow arbitrary computation, but I use most services because they have some data I want to use: their search index, their knowledge, their database of chemicals, my bank account transactions, whatever.
So unless Google lets me encrypt their entire search index, they can still see my query at the time it interacts with the index, or else they cannot fulfill it.
The other point is incentives: outside of some very few, high-trust high-stakes applications, I don't see why companies would go through the trouble and FHE services.
Here's an implementation of a fully private search engine using FHE that allows querying Wikipedia with the server remaining oblivious as to what you're reading: https://spiralwiki.com/
From what I understand, only the sensitive data needs to be encrypted (e.g. your bank transactions). It is still possible to use public unencryped data in the computation, as the function you want to compute doesn't have to be encrypted.
In a world where Target can figure out a women is pregnant before she knows herself due to her shopping habits, the line that separates sensitive data is pretty ambiguous.
Exactly what I thought. In the end it really isn't in most of the big corps interest to not see your data/query. They need/want to see it so why would they degrade their ability to do so if they can just say no and you will have to rely on using their services without FHE. For banking applications cool, everyone else debatable if it will ever be accepted.
You're right about incentives, but wrong about the first part. Private lookups of a plaintext database are possible and have been for a while now (5+ years?). The problem is it often requires some nontrivial preprocessing of the plaintext database, or in the worst case a linear scan of the entire database.
> Private lookups of a plaintext database are possible and have been for a while now (5+ years?). The problem is it often requires some nontrivial preprocessing of the plaintext database, or in the worst case a linear scan of the entire database.
So that basically means that if a company has data that my program might want to use, the entirety of that data needs to be loaded into my program. Not quite feasible for something like the Google search index, which (afaik) doesn't even fit onto a single machine.
Also, while Google is fine with us doing searches, making the whole search index available to a homomorphic encrypted program is probably a quite different beast.
You can process the data such that only a structured lookup table is shared with the client. That data structure is massive.
The use case isn't really “search Google without them knowing my query”, it’s search my own data without them knowing my data”. Which limits the practically applicable scope considerably.
> the entirety of that data needs to be loaded into my program
What? No. I'm not saying the entire Google search index is feasible, but you can do a lot. Here are some concrete numbers from what is now considered an "old" paper (2022; it has been improved since then)
To make queries to a 1 GB database [in a scheme called DoublePIR] the client must download a 16 MB "hint" about the database contents; thereafter, the client may make an unbounded number of queries, each requiring 345 KB of communication, and a throughput of 7.4 GB/s/core.
Which ultimately results in gigabytes of per-client-encrypted data needing to be downloaded, and regenerated and redownloaded every time the index is updated.
I guess another reason is that there isn't too much IT infrastructure that Russian trains depend on.
There are ticket sales systems for people being transported, but much is freight trains, and if there was an easy way to disrupt that, you can be sure that Ukraine would've done it by now, because the Russian military heavily depends on rail-based supplies.
On the other hand, once you have a well-established IT automation around your production, and people aren't trained in pre-automation production, it's actually quite hard to go back to manual.
Probably also depends on the complexity of the orders and workflows.
An outage of roughly 1 hour is 0.13% of a month or 0.0114% of a year.
It would be interesting to see the service level objective (SLO) that cloudflare internally has for this service.
I've found https://www.cloudflare.com/r2-service-level-agreement/ but this seems to be for payed services, so this outage would put July in the "< 99.9% but >= 99.0%" bucket, so you'd get a 10% refund for the month if you payed for it.
There's a constant tension between speed of detection and false positive rates.
Traditional monitoring systems like Nagios and Icinga have settings where they only open events/alerts if a check failed three times in a row, because spurious failed checks are quite common.
If you spam your operators with lots of alerts for monitoring checks that fix themselves, you stress the unnecessarily and create alert blindness, because the first reaction will be "let's wait if it fixes itself".
I've never operated a service with as much exposure as CF's DNS service, but I'm not really surprised that it took 8 minutes to get a reliable detection.
I work on the SSO stack in a b2b company with about 200k monthly active users. One blind spot in our monitoring is when an error occurs on the client's identity provider because of a problem on our side. The service is unusable and we don't have any error logs to raise an alert. We tried to setup an alert based on expected vs actual traffic but we concluded that it would create more problems for the reason you provided.
At Cloudflare’s scale on 1.1.1.1, I’d imagine you could do something comparatively simple like track ten-minute and ten-second rolling averages (I know, I know, I make that sound much easier and more practical than it actually would be), and if they differ by more than 50%, sound the alarm. (Maybe the exact numbers would need to be tweaked, e.g. 20 seconds or 80%, but it’s the idea.)
Were it much less than 1.1.1.1 itself, taking longer than a minute to alarm probably wouldn’t surprise me, but this is 1.1.1.1, they’re dealing with vasts amounts of probably fairly consistent traffic.
I work on something at a similar scale to 1.1.1.1, if we had this kind of setup our oncall would never be asleep (well, that is almost already the case, but alas). It's easy to say "just implement X monitor and you'd have caught this" but there's a real human cost and you have to work extremely vigilently at deleting monitors or you'll be absolutely swamped with endless false positive pages. I don't think a 5 minute delay is unreasonable for a service this scale.
This just seems kinda fundamental: the entire service was basically down, and it took 6+ minutes to notice? I’m just increasingly perplexed at how that could be. This isn’t an advanced monitor, this is perhaps the first and most important monitor I’d expect to implement (based on no closely relevant experience).
I don’t want to devolve this to an argument from authority, but - there’s a lot of trade offs to monitoring systems, especially at that scale. Among other things, aggregation takes time at scale, and with enough metrics and numbers coming in, your variance is all over the place. A core fact about distributed systems at this scale is that something is always broken somewhere in the stack - the law of averages demands it, and so if you’re going to do an all-fire-alarm alert any time part of the system isn’t working, you’ve got alarms going off 24/7. Actually detecting that an actual incident is actually happening on a machine of the size and complexity we’re talking about within 5 minutes is absolutely fantastic.
I'm sure some engineer at cloudflare is evaluating something like this right now, and try it on historical data how many false positives that would've generated in the past, if any.
Thing is, it's probably still some engineering effort, and most orgs only really improve their monitoring after it turned out to be sub-optimal.
This is hardly the first 1.1.1.1 outage. It’s also probably about the first external monitoring behaviour I imagine you’d come up with. That’s why I’m surprised—more surprised the longer I think about it, actually; more than five minutes is a really long delay to notice such a fundamental breakage.
Is your external monitor working? How many checks failed, in what order? Across how many different regions or systems? Was it a transient failure? How many times do you retry, and at what cadence? Do you push your success or failure metrics? Do you pull? What if your metrics don’t make it back? How long do you wait before considering it a problem? What other checks do you run, and how long do those take? What kind of latency is acceptable for checks like that? How many false alarms are you willing to accept, and at what cadence?
While all you say is true, it bears note that it didn't need to be decisive. The current mob branch of tcc is such that a `#!/bin/tcc -run` "script" is about 1.3x faster than perl</dev/null on two CPUs I tried.
Besides your two slower examples, Julia and Java VMs and else thread PHP also have really big start up times. As I said up top, people just get addicted to "big environments". Lisp culture would do that with images and this is part of where the "emacs is bloated" meme came from.
Anyway, at the time getline wasn't even standardized (that was 2008 POSIX - and still not in Windows; facepalm emoji), but you could write a pretty slick little library for CGI in a few hundred..few thou' lines of C. Someone surely even did.
But things go by "reputation" and people learn what their friends tell them to, by and large. So, CGI was absolutely the thing that made the mid to late 90s "Perl's moment".
The major modern use case I know of is command-line utilities which also benefit from low start-up. Of course, that doesn't mean there hasn't been "perf rot" over the decades as you say. Such rot should never surprise anyone. :-)
Some perl5 lover should take the time to compile all those 5.6 to 5.42 versions on the same host OS/CPU and do a performance comparison and create a nice chart for the world to trap and maybe correct such performance regressions. I just tried getting 5.8.9 to compile on modern Linux with gcc-15, and it seemed like a real PITA. (Earlier didn't even ./Configure -des right.)
Well, I spent a little more time on it, and for that one Perl version (on one cpu, i7-6700k, one OS - Linux 6.15, with one compiler gcc-15) I got a 1.5x slowdown of perl startup from 2008 to 2025. Not great!
zsh# rei=(chrt 99 taskset -c 2-3 env -i HOME=$HOME PATH=/bin)
zsh# tim=(-k2 -o14 -n14 -m14)
# Set 1
zsh# $rei tim $tim './perl-5.8.9</n' 'perl-5.42.0</n'
218.5 +- 1.9 μs (AlreadySubtracted)Overhead
626 +- 14 μs ./perl-5.8.9</n
953.5 +- 8.6 μs perl-5.42.0</n
# Set 2
zsh# $rei tim $tim './perl-5.8.9</n' 'perl-5.42.0</n'
247 +- 15 μs (AlreadySubtracted)Overhead
633 +- 26 μs ./perl-5.8.9</n
989 +- 25 μs perl-5.42.0</n
# Consistency check - well within 2 sigma for both
zsh# a (989 +- 25)-(953.5 +- 8.6)
36 +- 26
zsh# a (626 +- 14)-(633 +- 26)
-7 +- 30
# Final report; weighted means to maximize precision
zsh# a mean(989 +- 25,953.5 +- 8.6)/mean(626 +- 14,633 +- 26)
1.525 +- 0.033
EDIT: Oh, yeah, and /n -> /dev/null is a symlink I always use.
The abstract of the paper mentions temperature differential of 1.3°C and 2°C - not really inspiring for use in a refrigerator.
Neither the article nor the abstract go out of their way to compare the efficiency of the new system to traditional heat pumps. Makes it kinda hard for a lay person to really assess the situation.
If you haven't grown up with every semi-publicly spoken word recorded and made searchable, you aren't used to restrict what you say to those that you are OK with being recorded.
But, even more importantly, even if you do, you might later change your mind about things.
Part as a problem is that we, as a society, don't really deal appropriately (at least in my opinion) to old recordings. If somebody said something slightly offensive 10 years ago, and it wasn't recorded, basically nobody cares. If it was recorded, there's too much outrage, considering that this was one thing of literally 100k things they said that year.
Back when I started web development, there were standards, but nearly everybody just coded to what Internet Explorer supported. Which I really hated :-)
In the past few years, I've seen the occasional "works best with Chrome" website, which worries me, but so far it hasn't been too bad.
But if we as a community leave the browser market to Chrome and browsers with engines of similar origin as Chrome's, we'll get back to the bad old days.
reply