Working with Jenkins CasC, JobDSL and declarative pipelines, I'm not sure where the million times comes from. Sure, there are some annoying parts, and GHA has the social network for reusable actions, but apart from that it's not that different.
Oldschool maven type jobs where you type shell script into a `<textarea>`? Yeah, let's not talk about those, but we don't have a single one left anymore.
downdetectorsdowndetector.com does not load the results as part of the HTML, nor does it do any API requests to retrieve the status. Instead, the obfuscated javascript code contains a `generateMockStatus()` function that has parts like `responseTimeMs: randomInt(...)` and a hardcoded `status: up` / `httpStatus: 200`. I didn't reverse-engineer the entire script, but based on it incorrectly showing downdetector.com as being up today, I'm pretty sure that downdetectorsdowndetector.com is just faking the results.
downdetectorsdowndetectorsdowndetector.com and downdetectorsdowndetectorsdowndetectorsdowndetector.com seem like they might be legit. One has the results in the HTML, the other fetches some JSON from a backend (`status4.php`).
Also with additional control difficulty due to reduced hydraulic pressure.
> On the Boeing 767, the control surfaces are so large that the pilots cannot move them with muscle power alone. Instead, hydraulic systems are used to multiply the forces applied by the pilots. Since the engines supply power for the hydraulic systems, in the case of a complete power outage, the aircraft was designed with a ram air turbine that swings out from a compartment located beneath the bottom of the 767,[10] and drives a hydraulic pump to supply power to hydraulic systems.
> As the aircraft slowed on approach to landing, the reduced power generated by the ram air turbine rendered the aircraft increasingly difficult to control.[16]
> The forward slip disrupted airflow past the ram air turbine, which decreased the hydraulic power available; the pilots were surprised to find the aircraft slow to respond when straightening after the forward slip.
> Cloudflare’s critical Workers KV service went offline due to an outage of a 3rd party service that is a key dependency. As a result, certain Cloudflare products that rely on KV service to store and disseminate information are unavailable [...]
Surprising, but not entirely unplausible for a GCP outage to spread to CF.
Based on [1] it seems like one `management.endpoints.web.exposure.include=*` is enough to expose everything including the heapdump endpoint on the public HTTP API without authentication. It's even there in the docs as an example.
Looks like there is a change [2] coming to the `management.endpoint.heapdump.access` default value that would make this harder to expose by accident.
Going a bit further, it seems like there's a grain of truth here, HTTP/2 has a stream priority dependency mechanism [1] and this report [2] from Imperva describes an actual Dependency Cycle DoS in the nghttp implementation.
Unfortunately that's where it seems to end... I'm not that familiar with QUIC and HTTP/2, but I think the closest it gets is that the GitHub repo exists and has a `class QuicConnection` [3]. Beyond that, the QUIC protocol layer doesn't have any concept of exchanging stream priorities [4] and HTTP/2 priorities are something the client sends, not the server? The PoC also mentions HTTP/3 and PRIORITY_UPDATE frames, but those are from the newer RFC 9218 [5] and lack the stream dependencies used in HTTP/2 PRIORITY frames.
That graph doesn't seem to make a very clear distinction between historical, real-time and predicted values... I think the event happened at 12:30 local time or so.
There seems to be some kind of recurrent daily pattern where the French - Spanish interconnect switches from Spain -> France imports to France -> Spain exports at around that time, and then back again in the late afternoon.
It looks like the Iberian peninsula is relatively isolated from the rest of the CESA synchronous grid, with only 2% cross-border capacity compared to local generation. [1]
There's a map at [2]
> The Spanish electricity system is currently connected to the systems of France, Portugal, Andorra and Morocco. The exchange capacity of this interconnection is around 3 GW, which represents a low level of interconnection for the peninsula. The international interconnection level is calculated by comparing the electricity exchange capacity with other countries with the generation capacity or installed power.
Yeah, and that makes sense in the context of an acceptable use policy for Mozilla services that are not your use of the Firefox browser.
But the same AUP for the services is now explicitly referenced in the TOS for the browser. How are you supposed to read it - the AUP only applies to your use of the browser to access the services? Isn't that already implicit if you're using the services? Surely it can't be attempting to apply the services AUP to any non-service use of the browser?
Very confusing, it seems badly written to me.
Same thing with the "Some Services in Firefox Require a Mozilla Account" and then the "Termination" with a notification to the (optional) account. Somewhat disconcerting.
[1] Mozilla can suspend or end anyone’s access to Firefox at any time for any reason, including if Mozilla decides not to offer Firefox anymore. If we decide to suspend or end your access, we will try to notify you at the email address associated with your account or the next time you attempt to access your account.
Wait, Mozilla is banning the use of their Firefox browser for porn? That's going to hurt adoption.
What's with the mixup of their browser and services policies?
[1] Your use of Firefox must follow Mozilla’s Acceptable Use Policy, and you agree that you will not use Firefox to infringe anyone’s rights or violate any applicable laws or regulations.
[2] You may not use any of Mozilla’s services to:
* Upload, download, transmit, display, or grant access to content that includes graphic depictions of sexuality or violence,
It's fascinating that we've built a system that has expended perhaps several million dollars of engineering, legal and admin etc time over the issue of a single letter not being capitalized [1], without any demonstrable impact beyond a failure to meet ambiguous specifications.
I do hope that dealing with all of the underlying issues around revocation etc makes the time and effort spent useful, and the Web PKI doesn't just mire itself in squabbling that blocks progress on actually meaningful issues.
These are technically kinda crazy, because they use a normal schuko plug (with male pins) to output power. It allows loading the circuit with a higher total ampacity than the circuit breaker protecting the wiring at the distribution panel. It takes a very specific set of regulations to make these legal, and those don't apply elsewhere in Europe.
Renewing the certificates seems technically pointless, but some organizations/federations require it.
Rotating the keys would make some sense, but just swapping the cert for a new one issued against the same keys doesn't. It's the easiest way to fulfill those requirements, because you don't need to synchronize the metadata updates, the signatures are always valid with both the old and new cert.