We have OnlyOffice as an alternative today. Personally I find the UI quite pleasing. But lately I haven't had any need to use office suite at home so I don't really use it so I have yet to find anything to complain (meanwhile, LibreOffice was horrible, while Office 365 was bearable until you stuff too many things in the equation editor).
Its really not that bad. I used to use it at work all the time. I did word processing, spreadsheets and presentations all the time with it. Maybe not as powerful as Excel, but I was never really a power user. But then again I never saw any spreadsheets that anybody used that were particularly complex.
> The one use case where a DB backed queue will fail for sure is when the payload is large. For example, you queue a large JSON payload to be picked up by a worker and process it, then the DB writing overhead itself makes a background worker useless.
redis would suffer from the same issue. Possibly even more severely due to being memory constrained?
I'd probably just stuff the "large data" in s3 or something like that, and just include the reference/location of the data in the actual job itself, if it was big enough to cause problems.
One problem with this is it often leads to a missing stair[1] syndrome for new users not knowing whom to block and finding the place overall too toxic.
For grid storage the only two things that matter are cost and reliability. So it would be a big deal, but it's not the public for whom it would be the biggest deal.
I think light aircraft doing short flights might be pretty interested by the technology. I remember 400 Wh being a threshold above which flights become feasible.
reply