Being pedantic, the modern engines that you're talking about don't run at 20,000 RPM either, they are limited to 15,000 RPM and I believe they basically never actually reach that limit, usually topping out at 12,000-13,000 instead.
When the engines did run closer to 20,000 they were indeed rebuilt much more often. I am not well versed in F1 regulation history but Wikipedia claims that before 2005 engines were not required to last for two race weekends[1], meaning you could rebuild the engine between each race weekend if you wanted to. At that time there was no RPM limit[2] for the engines and the iconic Ferrari F2004 supposedly maxed out at 19,000 RPM[3].
So maybe the comment you are replying to is referring to pre-2005 F1 engines :) I have no idea myself if a modern F1 engine could run at 20,000 and still be as durable as the current engines or if running at such high RPM inherently means bad durability.
Yes, the goal is that it should be usable in production as well. The limitation it will probably have compared to ELK/Splunk is that since there's only a single recipient node and it uses SQLite for storage, the upper limit to how quickly it can ingest logs will probably be lower compared to ELK/Splunk. So Logsuck may not ever be suitable for large deployments that are logging huge amounts for sustained periods of time.
I haven't really tested what the limits are yet so unfortunately I can't put a concrete number on it, but my vision is that Logsuck should at the very least work for a small-medium sized company with "normal" logging needs.
The current state is that it's got quite a few bugs and is lacking many features you would expect from an ELK/Splunk alternative but the basic concept is working. If what you need is a GUI for grepping across logs spread out on multiple servers it can be used for that today, but it's not doing much beyond that yet.
I think I know what you mean! It does feel like there's something missing in Splunk when it comes to analyzing issues.
When there's a problem at work it's usually easy to see that something is wrong on a dashboard, but when I want to drill down into it I usually end up with ten tabs of different searches and Grafana dashboards that I'm trying to correlate between manually.
I haven't fully formed any ideas about how to tackle this since there are still fairly basic features missing in Logsuck that I need to work on first but it's definitely something I'll be thinking more about in the future!
Interesting! I have it in the backlog that I want to support structured logging via JSON at some point. It's pretty far down the list right now though since I personally haven't used structured logging very much.
Glad you like it! Completely agree about the overkill-ness of ELK.
I haven't had a chance to try Datadog yet but it looks great, the one complaint I've had with Splunk (or at least the way we use it at work) is that it's still "Just logs" and sometimes you need more than that to investigate issues while Datadog seems to cover more areas of monitoring in one package.
Currently it's not used in production anywhere, I mostly use it to view my own log files when I'm working on some hobby project locally, so I'm sure there are a few issues that would show up if it was used more heavily.
I do have a list of known issues on a private Trello board, I should probably move those to GitHub so that they are at least visible to people, I'll take care of that right away.
There is some info in the readme on how to get started, if you want to try it out and need any help beyond that let me know!
The idea is to have a free Splunk alternative which you can set up with just one binary. I use Splunk at work and love it, but it just doesn't seem like a product for solo developers (I can't even find a pricing page on splunk.com), and the primary free alternative, the ELK stack, seems a bit complicated to set up.
I am sure that I'll never be competitive with Splunk or Elastic in terms of features or scalability but I'm trying to build something that is at least useful for my own projects.
I built it in Go and use SQLite with the FTS (https://sqlite.org/fts3.html) extension to store the log events in a way where they can be searched quickly.
I doubt it's what's being done in this case but an interesting take on this topic is "rollback netcode" which AFAIK was originally used for playing emulated arcade games over the internet.
The idea is that the host guesses what the other player's inputs are on a certain frame, and when the actual input then arrives the host emulator will roll back its state to that frame and then re-emulate the frames after it, if it guessed wrong. If it guessed right the game continues as usual.
It's a good fit for emulation since "rolling back" in an emulator is usually easier than rolling back the state in a game that wasn't built with this type of netcode in mind, but it has also become a popular type of netcode for modern fighting games.
I believe bfgx[0] is similar to what you're describing. It's been around since before the Vulkan/DX12/Metal era so the abstractions are more similar to OpenGL/DX11 where you don't have concepts like command buffers and command queues etc, which might be a turn off.
Big open source projects still seem to roll their own solution for this, which I imagine is both for historical reasons but also because there might be a fear that using a library like this could leave your hands tied when you need to do some API-specific workaround.
You can use it for doing server side rendering of React or other JS framework components. I have a VERY rough repository[0] where I tested this out a while back. The way I did it was to export functions on the global object in JS[1] which could then easily be called from Java code[2]. I'm sure there's a better way to accomplish the same thing.
What I found interesting with this approach is that it allows you to do server side rendering without needing a separate server and without needing any third party dependencies aside from GraalVM itself.
I agree in principle that it's nice to be able to see the full conversations without clicking into a bunch of threads, but a problem that I have noticed when people use Mattermost is that they either forget or don't notice that people are using the thread feature and simply reply directly in the channel to an active thread. This makes it so that anyone who isn't looking at the channel loses track of the conversation. You could fix this by repeatedly telling anyone who does it wrong to do it right, but people simply can't make that mistake when the threads are collapsed by default.
As things are now, the thread feature in Mattermost doesn't really help that much, because if you want to be really sure not to miss part of a conversation you need to keep a separate window with that channel open anyway instead of just having the thread open in the same window.
When the engines did run closer to 20,000 they were indeed rebuilt much more often. I am not well versed in F1 regulation history but Wikipedia claims that before 2005 engines were not required to last for two race weekends[1], meaning you could rebuild the engine between each race weekend if you wanted to. At that time there was no RPM limit[2] for the engines and the iconic Ferrari F2004 supposedly maxed out at 19,000 RPM[3].
So maybe the comment you are replying to is referring to pre-2005 F1 engines :) I have no idea myself if a modern F1 engine could run at 20,000 and still be as durable as the current engines or if running at such high RPM inherently means bad durability.
1. https://en.wikipedia.org/wiki/2005_Formula_One_World_Champio...
2. https://en.wikipedia.org/wiki/Formula_One_engines#Engine_spe...
3. https://www.f1technical.net/f1db/cars/873/ferrari-f2004