I was partying on more Userspace<T> changes, this time pushing the
type system down through sys$write(..) / FileDescription::write(...) /
File::write and all the derived implementations. However I ran into a
stumbling block, which leads to a potentially interesting design
problem.

I naively assumed all writes would come from userspace, which is why I
started pushing Userspace<T> all the way down into the Device/File
API. However that assumption is violated in a few places, for example
by BlockBasedFS::flush_specific_block_If_needed().

255 void BlockBasedFS::flush_specific_block_if_needed(unsigned index)
256 {
257     LOCKER(m_lock);

Hacktoberfest 2020 is coming up soon.
https://hacktoberfest.digitalocean.com/

Would it make sense to sketch out small projects and tasks that the
Serenity community would benefit from? We can tag them in the issue
tracker to encourage folks to participate in Hacktoberfest, and hack
on Serenity. Projects that prepare and setup up for grab issues
normally get a pretty big influx of contributors during the month,
which you can view as a good or bad thing. :)

Something I've wanted that might make a nice little project for
someone is a Flame Graph rendering for the profile viewer.
http://www.brendangregg.com/flamegraphs.html
I don't think it would be a ton of work to get something bare bones going.

Random idea... what about removing abort from the assert completely?

Instead serenity could use an unused software interrupt code to
trigger the assert crash.
Then you can just inline the assert everywhere.

Windows does something similar to allow processes to force terminate
by just running a single instruction.
https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail?view=vs-2019