Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment Re:Bad design (Score 1) 97 97

It's a car. There will always be the physical component as a point of failure. Adding an electronic component on top of that adds another point of failure. In some cases the function is too important to add unnecessary points of failure.

I would try to think of a car analogy, but ...

Comment Re:Excuse to keep using oil (Score 1) 249 249

Fortunately, some of us had the foresight to see this coming. It's just a matter of releasing sequestered CO2 into the atmosphere to help protect us from these kinds of natural events. Unfortunately most people aren't equipped to do their part to combat this.

To that end I have started a charitable organization that can do the work to supplement the CO2 in our atmosphere. To make it easier for others who cannot do this themselves, we will sell Carbon Debits to allow others to offset their carbon production deficiencies.

Some may mistake this as some elaborate scheme to make great amounts of wealth and resources disappear in a puff of smoke. I assure you, our methods are far more sophisticated than that.

Comment Re:kinda dissapointed... (Score 1) 187 187

What you quote is not a commitment to a standard format. It merely documents the behaviour of the current implementation. My statement stands. The format's not standardized. The developers have asserted freedom to change it. I have not seen that recanted. All simple facts. Show me the statement that the format has been locked down.

The current text logs can be read it with less, more, cat, vi or any number of other tools. If the journal format gets locked down, then I should be able to grab any old journal reading tool on any rescue image to read it. That is just not the case today. As you point out, today I must have the latest version of journalctl to be sure I can read the journal on any arbitrary system and that's still not promised to be the case tomorrow.

It's an interesting debate, but I don't intend to carry on. If you don't consider reliably readable boot logs a big deal in any practical sense, that's your opinion. If you just want to re-affirm that you believe the current state of things are acceptable, that's good for you. If you can find a reference that shows upstream intends to lock down the journal format definition, that would be good news and worth knowing.

Comment Re:kinda dissapointed... (Score 1) 187 187

And the format documentation you pointed at said

Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right.

This document describes the current format of systemd 195. The documented format is compatible with the format used in the first versions of the journal, but received various compatible additions since.

Somebody documented a current snapshot but that doesn't tell me that the format has been standardized in any way.

The code that generated the journal is the only authority on the format of the generated journal. If you want to be sure you can read it, you need the same code or a promise that the documentation does not make.

So unless you can point me at the doc that says they have commited to a standard format, I re-assert

the binary format of the logs are not standardized. They are free to change between releases. Specifically, this was meant that you would need the version of journalctl that was compiled with version of systemd that was running.

Comment Re:kinda dissapointed... (Score 1) 187 187

https://docs.google.com/docume...

Will the journal file format be standardized? Where can I find an explanation of the on-disk data structures?

At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. The access is granted by a shared library and a command line tool. (But then again, it’s Free Software, so you can always read the source code!)

Comment Re:kinda dissapointed... (Score 1) 187 187

Just a comment.

And what's the difference if SystemRescueCD ships journalctl alongside grep and emacs to show me system-log files?

If I recall correctly, the binary format of the logs are not standardized. They are free to change between releases. Specifically, this was meant that you would need the version of journalctl that was compiled with version of systemd that was running. This was touted as one of the security (through obscurity) features of systemd's logging.

While upgrading, to debug you may need a rescue CD of the old release and a rescue CD of the new release. Or the rescue CD will have to bundle multiple versions of journalctl. Or someone else will have to come in and enforce a standard log format that systemd's maintains do not intend to provide.

The more data I punch in this card, the lighter it becomes, and the lower the mailing cost. -- S. Kelly-Bootle, "The Devil's DP Dictionary"

Working...