Happened on the first day of my first on-call rotation - a cert for one of the key services expired. Autorenew failed, because one of the subdomains on the cert no longer resolved.
The main lesson we took from this was: you absolutely need monitoring for cert expiration, with alert when (valid_to - now) becomes less than typical refresh window.
It's easy to forget this, especially when it's not strictly part of your app, but essential nonetheless.
I believe every sensible open-source developer strives to keep their software performant. To me, a performance regression is a bug like any other and I got and fix it. Sure, there's no warranty guaranteed in the license, yet no-one who takes their project even a little seriously takes it as "I can break this any way I want".
The question is, does Mozilla rigorously review every single update of every featured extension? Or did they just vet it once, and a malicious developer may now introduce data collection or similar "features" though a minor update of the extension and keep enjoying the "recommended" badge by Mozilla?
This may also be the reason for the extension begin "Featured" on the Chrome Web Store: Google vetted it once, and didn't think about it for each update.
That link doesn't answer the question though. It states that the extension is reviewed before receiving the recommended status. It does not state that updates are reviewed.
They do, and it takes longer for updates to Recommended extensions to be reviewed as a result.
This is what the Firefox add-ons team sent to me when one of my extensions was invited to the Recommended program:
> If you’re interested in Control Panel for Twitter becoming a Firefox Recommended Extension there are a couple of conditions to consider:
> 1) Mozilla staff security experts manually review every new submission of all Recommended extensions; this ensures all Recommended extensions remain compliant with AMO’s privacy and security standards. Due to this rigorous monitoring you can expect slightly longer review wait times for new version submissions (up to two weeks in some cases, though it’s usually just a few days).
> 2) Developers agree to actively maintain their Recommended extension (i.e. make timely bug fixes and/or generally tend to its ongoing maintenance). Basically we don't want to include abandoned or otherwise decaying content, so if the day arrives you intend to no longer maintain Control Panel for Twitter, we simply ask you to communicate that to us so we can plan for its removal from the program.
I always enjoyed being a metal head, the music is the main reason of course (I like it), but the community is a very big aspect of it too.
I always thought about metal shows and festivals as a "safe space", where people can really be themselves, because you don't have to suffer judgmental remarks about what you wear, what you look like or what you listen to. And most people there get this and feel this as well, which is why the community feels so welcoming and chill. Plus as someone else posted here, it's also all a bit silly and I think most people get that as well.
It's not that long ago that tables were the only reliable layout tool for HTML emails (mostly due to Outlook supporting only very limited subset of CSS).
I would guess this is just to make the explanation of the bug easier.
In real world, the futurelock could occur even with very short locks, it just wouldn't be so deterministic. Having a minimal reproducer that you have to run a thousand times and it will maybe futurelock doesn't really make for a good example :)
>In real world, the futurelock could occur even with very short locks, it just wouldn't be so deterministic.
You have to explain the problem properly then. The problem here has nothing to do with duration whatsoever so don't bring that up. The problem here is that if you acquire a lock, you're inside a critical section. Critical sections have a programming paradigm that is equivalent to writing unsafe Rust. You're not allowed to panic inside unsafe Rust or inside critical sections. It's simply not allowed.
You're also not allowed to interrupt the critical section by something that does not have a hard guarantee that it will finish. This rules out await inside the critical section. You're not allowed to do await. It's simply not allowed. The only thing you're allowed to do is execute an instruction that guarantees that N-1 instructions are left to be executed, where N is a finite number. Alternatively you do the logical equivalent. You have a process that has a known finite bound on how long it will take to execute and you are waiting for that external process.
After that process has finished, you release the lock. Then you return to the scheduler and execute the next future. The next future cannot be blocked because the lock has already been released. It's simply impossible.
You now have to explain how the impossible happened. After all, by using the lock you've declared that you took all possible precautions to avoid interrupting the critical section. If you did not, then you deserve any bugs coming your way.
That's just how locks are.
I think you misunderstand the problem. The only purpose of the sleep in this example is to control interleaving of execution to ensure the problem happens. Here's a version where the background task (the initial lock holder) only runs a bounded number of instructions with the lock held, just as you suggest:
> After that process has finished, you release the lock. Then you return to the scheduler and execute the next future. The next future cannot be blocked because the lock has already been released. It's simply impossible.
This is true with threads and with tasks that only ever poll futures sequentially. It is not true in the various cases mentioned in this RFD (notably `tokio::select!`, but also others). Intuitively: when you have one task polling on multiple futures concurrently, you're essentially adding another layer to the scheduler (kernel thread scheduler, tokio task scheduler, now some task is acting as its own future scheduler). The problem is it's surprisingly easy to (1) not realize that and (2) accidentally have that "scheduler" not poll the next runnable future and then get stuck, just like if the kernel scheduler didn't wake up a runnable thread.
I was involved in porting some software to Qt back when Photon was deprecated, and I always found the system very interesting. This is the first time I'm actually learning more about its history. Thanks for the great read.
I was also a huge fan of BlackBerry phones (having used Q5 and Z10 as daily drivers). The system was solid and had some really cool ideas. Too bad it didn't work out...
It's more about having the LLM give you a plan of what it wants to do and how it wants to do it, rather rhan code. Then you can mold the plan to fit what you really want. Then you ask it to actually start writing code.
Even Claude Code lets you approve each change, but it's already writing code according to a plan that you reviewed and approved.
This is my gripe with C++ - I have to have a CI pipeline that runs a job with clang-tidy (which is slow), jobs with asan, memsan and tsan, each running the entire test-suite, and ideally also one job for clang and one for gcc to catch all compiler warnings, then finally a job that produces optimized binaries.
With Rust I have one job that runs tests and another that runs cargo build --release and I'm done...
The main lesson we took from this was: you absolutely need monitoring for cert expiration, with alert when (valid_to - now) becomes less than typical refresh window.
It's easy to forget this, especially when it's not strictly part of your app, but essential nonetheless.