Please create an account to participate in the Slashdot moderation system


Forgot your password?
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Re:Wait for it ... (Score 1) 733

Lennart Poettering's long story short: "`su` is really a broken concept.

One day, systemd will become too complex or something ... Lennart will declare it a "broken concept" and absorb it into systemd.

At which point it will collapse in upon itself producing a singularity, the nature of which we currently lack the ability to truly understand. Then it will truly suck.

Comment Re:Startup management subsystem (Score 1) 416

The best part is the service descriptor files follow a standard. If all people did at this conference was convert package init scripts to systemd I would be ecstatic.

Honest question (to who ever might know) ... are systemd service descriptor files distribution independent?

People will tell you init scripts can be and can point you to standards for writing them, but in practice it usually doesn't work out too well. Not in a way that takes advantage of the various features of any given system. Distributions tend to be unique in various ways.

I'm just wondering if systemd fixes that or if each distro is still going to have to roll their own because of distro unique conventions? And of course there's the corollary question, is the plan to fix this by forcing distributions to all behave the same? (e.g "You will do it this way because systemd will not allow anything else.")

Comment Re:Excuse to keep using oil (Score 1) 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

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

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

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

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.

Anything cut to length will be too short.