10987654321

It depends on the solution, Loki for instance has support for it: https://grafana.com/blog/2019/08/13/lokis-path-to-ga-live-ta...

With that said unless you tune your query it's very easy to get overwhelmed once you scale a bit and start getting larger log volumes.

Congratulations on the release! I've been following the development blog for a fair while and backed the kickstarter and am very happy to see this game finally getting released (and OSS no less).

I've been looking into making my own game using the Trial engine but I was a bit scared off by the warnings about API stability and lack of documentation. Now that Kandria is released, is the API stabilized? And I guess the Kandria source code can work as documentation on how to set things up..

Hmmm, it doesn't say in https://lnav.org/features#automatic-log-format-detection but i see that at least json (and xml) is mentioned under the pretty-printing header.

You would know what is supported what with you being the author, just saying that the docs aren't super clear from a quick glance :).

And yes, I second the suggestion to focus on JSON. The main benefit of logfmt is that it's simpler for a human to parse directly but in general you probably shouldn't aim for that so..

Another benefit with json/logfmt that bears mentioning explicitly: it has structure.

This means that you shouldn't just write (to reuse the previous example):

    msg="Request for brandur@mutelight.org finished with status 200"

you should do it like

    msg="Request finished" status=200 user=brandur@mutelight.org

and not put any variables into the msg key (and not really do advanced formatting for any of the keys for that matter). This way once you get it put into a log system that understands your format you can do searches like "all log messages where user=foo" or "all statuses that are >=500 and <600" or search on specific messages, all without having to craft elaborate regular expressions and with better performance since the log search system can do indexing and various optimizations so that it doesn't have to be a full-text search every time.

> writing to specific block locations would then be wiping unrelated inodes depending on the low level logic

It won't wipe unrelated files as far as the file system sees it, but it might overwrite some previously discarded internal blocks. "inodes" is a too high-level concept in this context.

You can read more about it on wikipedia which might be an authorative enough source for you? https://en.wikipedia.org/wiki/Wear_leveling

Also note that most ssds actually have more internal blocks available than what they present to the host device so that they can have a "cache" to be able to move things around internally, and also so they can mark certain positions as "bad" when writes to one internal block start failing and still operate properly.

In general if you use things like filebeat or promtail to do log ingestion into centralized log search systems (elasticsearch or loki in these examples) they prefer one object per line.

It makes parsing and keeping track of the "state" of the file a lot easier. Say that your application crashes/gets killed halfway through writing a log message / json dict and then gets restarted and appends to the log file. How should the log reader handle that case if it suddenly becomes a valid nested object? And even if it doesn't, should it throw away the first new log message as well because that was embedded in the invalid json object? Much easier to just say "one line is one json object, if there are literal newlines that's the delimeter to start a new parse".

And yes in any case it's good to have a timestamp on your log message no matter the format, unless you're logging somewhere you know that it gets added immediately (like the systemd journal). Your log parser/forwarder can add a timestamp for when it reads your log message but that is not necessarily the same as when your application emits it.

Not sure about lnav but most log aggregation systems support json and logfmt-formatted logs, and there are many standard logging libraries that supports emitting those formats

Of those json is better if you want to be able to do more advanced stuff (nest dictionaries, use lists, ...) and logfmt is better if you want to have human-readable logs without external tools as well, an example line can look like

    msg="Request finished" tag=request_finish status=200 user=brandur@mutelight.org user_id=1234 app=mutelight app_id=1234

Some more info here https://www.brandur.org/logfmt

As someone who doesn't use ECC memory for my NAS (I'm not google) I have experienced many bitflips / corruptions for some sets of photos, especially when using a NAS with what turned out to be bad ram sticks (which was recognized after switching to using ZFS and raid 10, I don't know if this saved any of my data but the setup at least made me recognize that I had a problem).

Since Godot is MIT-licensed (which only requires a copyright notice and a note that says 'this is using code from a thing under the MIT license') changing the license would be trivial.

Essentially they could release "Godot current+1" under a fully proprietary (or GPL for that matter) license and keep the notice that's required by "Godot current" and they would be compliant, since "Godot current+1" would be a derived work from "Godot current".

The requirement to get consent from all previous contributors only applies if they would want to remove that copyright notice. For sofware that is under more restrictive licenses, like GPL, further restrictions apply and then it would be necessary to get an ok from all copyright holders to change the license to something that is incompatible with the GPL (or between incompatible GPL-versions, like GPLv2->GPLv3).

edit: While it would be ok to do this change from a licensing perspective it would of course most likely piss off quite a lot of the current contributors who didn't agree with the change, and they would most likely move to the aforementioned fork that would get started immediately.

Godot is MIT-licensed so no, they can't arbitrarily revoke your license and force you to stop developing your game.

What they could theoretically do is stop developing it, or change the license for all newer versions of the engine to one that would force you to pay to use it (or similar). In which case Godot would most likely be forked on the same day and a big part of the current developers would just move over to the fork.

Just checked and for the location where I have my vm the price is:

> Snapshots cost €0.0125/GB/month (incl. 25 % VAT)

so €20 would cover a month for about 1.6TB of snapshots. Sounds pretty reasonable to me. But I guess it depends on how much data OP lost.

Yes that was somewhat my point :)

And even if you don't have a drivers license it can be perfectly legal to drive your car on your own property (hack your own computers) but not to drive on public roads / private property where the owner has not consented to you driving (hacking someone elses computer without their ok), but if they are ok with it it's perfectly legal (like for instance pentesting). Context matters.

Or like saying that "The right to own a car does not mean that you have the right to drive it".

Or even "The right to own a car does not mean that you have the right to drive through red lights".

The fact that you can own something does not mean that you have the right to use it indiscriminately. In this case (if we consider them "digital arms") I don't see how using it for retribution (rather then self defense) would be considered ok.

I would hope so. These patents are ridiculous. Not that I'm a fan of putting a surveillance device into my house.

Probably you drank way too much "pure" water, and you upset your salt balance. Most likely if you had had some salts in the water you would have been better off (if not fine).