As others have already pointer out, you are wrong for assuming this is like systemd, so I won't further beat that horse.
However I think it's foolish for Shuttleworth to go down this path. It's inevitable that systemd will start to require that it get's it's hooks into package management. Long story short, the way fixes are applies to systems is fundamentally broken. Whether it's because someone can't find a way to tell what needs to be restarted or can't impose a way to restart all services without down time or can't find a way to apply changes to all containers or whatever half thought out problem is the excuse, it's broken. And the only fix will be to bundle it into the logic of systemd. Amongst other things, a package format will need to be mandated because supporting multiple formats is stupid or hard or out-of-scope... you name it.
No one has been able to oppse the systemd maintainers except the kernel developers when it comes users space interfaces. Canonical hasn't been able to stand its ground against these developers in the past. I doubt they will in the future either. Shuttleworth is creating another failure.
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.
Thanks for the reply. So I guess I'm not sure if that means systemd is implemented in a way to prevent deviations and differentiation or if it's just going to be the systemd team mandating "the right way" to make a Linux system.
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.")
...and tell them it dates to 1992, when high-end PCs were shipping with mayyybe 16-32GB RAM, a single 486 processor, 640x480x16 graphics, a few dozen megabytes of storage, and no networking.
I know I wasn't buying high end at the time, but I didn't think I was I slumming it that much.
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.
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.
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.
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.
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!)
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.
If they lose dominance and get desperate, I'd trust them less. Right now the threat of patents is just a scare tactic. If they get hurt for money, they'll become another SCO.
- The US government succeeds in anti-trust action against MS. Certain other world governments take action of their own.
You realize that case was a long time ago and a lot of the behavior I was discussing happened after that.
- Several strong competitors emerge who dominate in related areas of phones, tablets, cloud, search, social media, etc. Which leads us to:
- The market changes where the dominance in desktop OS is no longer the dominant factor in computing
I'll admit, that's reason for them to do something desperate. Having competition again does not imply Microsoft has become trustworthy.
- New leadership takes the reins at MS
... for the second time.
- MS begins to open-source their software, not because they suddenly received a vision from the Prophet Richard Stallman, but because they recognize that the old model of "embrace and extend" simply doesn't work anymore.
You are assuming a reason and an intent. That is where I am lead to believe differently than you.
If that's not enough, what is?
Microsoft spent decades working hard to earn the reputation they have. And I have to accent that. They earned their reputation. For a start, how about one decade of reasonable decent behavior without dirty secrets of back stabling coming to light in that time. Maybe one decade for 3+ is too much to ask?
I would take it to mean that the reporter is merely quoting the officials as opposed to corroborating that it was in fact an attempted "penetration" as opposed to being an attempted "bombing" or "protest" or "delivery" or "request for directions" or "wrong turn".
Slashdot Mirror
As others have already pointer out, you are wrong for assuming this is like systemd, so I won't further beat that horse.
However I think it's foolish for Shuttleworth to go down this path. It's inevitable that systemd will start to require that it get's it's hooks into package management. Long story short, the way fixes are applies to systems is fundamentally broken. Whether it's because someone can't find a way to tell what needs to be restarted or can't impose a way to restart all services without down time or can't find a way to apply changes to all containers or whatever half thought out problem is the excuse, it's broken. And the only fix will be to bundle it into the logic of systemd. Amongst other things, a package format will need to be mandated because supporting multiple formats is stupid or hard or out-of-scope ... you name it.
No one has been able to oppse the systemd maintainers except the kernel developers when it comes users space interfaces. Canonical hasn't been able to stand its ground against these developers in the past. I doubt they will in the future either. Shuttleworth is creating another failure.
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.
"Behold, the Underminer! I'm always beneath you, but nothing is beneath me!"
Thanks for the reply. So I guess I'm not sure if that means systemd is implemented in a way to prevent deviations and differentiation or if it's just going to be the systemd team mandating "the right way" to make a Linux system.
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.")
...and tell them it dates to 1992, when high-end PCs were shipping with mayyybe 16-32GB RAM, a single 486 processor, 640x480x16 graphics, a few dozen megabytes of storage, and no networking.
I know I wasn't buying high end at the time, but I didn't think I was I slumming it that much.
Having done a google image search on that, neither can I.
If they can't fix you, were you really vulnerable to begin with? Sprints shoddy ...err... selective network is a security feature.
Then for the trifecta, could we get a way to detect and prevent rebinding of standard keys?
you to is them.
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 ...
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.
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.
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.
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!)
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.
Well, a successful attempt is still an attempt: Netscape died.
But it failed, you need to learn your history: Netscape lived on thanks to Mozilla ...
Why couldn't we have been so lucky as to have Microsoft live on as Netscape has?
There are safer ways to do it.
When my friends need new bottoms there's only one word I tell them, Bottomy.
Zita Masciola Arlington, Texas
And I just read about "the world’s first mature grocery."
Why did Atheros use it? And was it theirs to "give".
What do you mean? They have an ocean right there.
If they lose dominance and get desperate, I'd trust them less. Right now the threat of patents is just a scare tactic. If they get hurt for money, they'll become another SCO.
Here are some possible turning points:
- The US government succeeds in anti-trust action against MS. Certain other world governments take action of their own.
You realize that case was a long time ago and a lot of the behavior I was discussing happened after that.
- Several strong competitors emerge who dominate in related areas of phones, tablets, cloud, search, social media, etc. Which leads us to:
- The market changes where the dominance in desktop OS is no longer the dominant factor in computing
I'll admit, that's reason for them to do something desperate. Having competition again does not imply Microsoft has become trustworthy.
- New leadership takes the reins at MS
... for the second time.
- MS begins to open-source their software, not because they suddenly received a vision from the Prophet Richard Stallman, but because they recognize that the old model of "embrace and extend" simply doesn't work anymore.
You are assuming a reason and an intent. That is where I am lead to believe differently than you.
If that's not enough, what is?
Microsoft spent decades working hard to earn the reputation they have. And I have to accent that. They earned their reputation. For a start, how about one decade of reasonable decent behavior without dirty secrets of back stabling coming to light in that time. Maybe one decade for 3+ is too much to ask?
I would take it to mean that the reporter is merely quoting the officials as opposed to corroborating that it was in fact an attempted "penetration" as opposed to being an attempted "bombing" or "protest" or "delivery" or "request for directions" or "wrong turn".