19 Sep
2012
19 Sep
'12
10:29
Cristian Rodríguez wrote:
El 15/09/12 11:49, Per Jessen escribió:
---
I assume the full power of linux's text utilities can be
used on them - like grep, sort, awk, perl... vim...
Having logs recorded in a non-text binary format tends to
make MS logs out-a-sight, out-a-mind, where as I often go and poke
around in /var/log and look to see if I notice anything 'new'.
If I can't look at the whole stream as a text (messages, warnings, etc),
I don't get a field for what is right or wrong behavior and certainly
wouldn't be able to pick out an anomaly if I had to query each item separately --
that global view is a good way to look for 'warts'...
MS makes it much to painful to do hat -- 1 error / page, everything in
300 separate queries ... ug!
I do want to log, but I've looked at the
journal already and didn't see
anything that wasn't already in /var/log/messages, /var/log/mail etc.
Seems like a duplication of effort and a waste of space in
/var/log/journal. (which afaict can just be deleted).
It is significantly more powerful than traditional logging:
For example
journalctl /usr/bin/foo --> get messages from program foo
journalctl /dev/sda --> hard-drive problems ?
journalctl -p error --> only errors
Currently it is not a full replacement for syslog but
I suggest you to
check it out.
I tend to use ngsyslog for the filtering benefits. -- really has some powerful
filtering in the 2.x line -- had to label ng3x taboo, so it won't overwrite
a working config with a non working config...
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
19 Sep
19 Sep
10:53
Linda Walsh wrote:
Ditto - also much easier to configure than rsyslog.
--
Per Jessen, Zürich (12.4°C)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Cristian Rodríguez wrote:
Same here.
El 15/09/12 11:49, Per Jessen escribió:
---
I assume the full power of linux's text utilities can be
used on them - like grep, sort, awk, perl... vim...
Having logs recorded in a non-text binary format tends to
make MS logs out-a-sight, out-a-mind, where as I often go and poke
around in /var/log and look to see if I notice anything 'new'. I do want to log, but I've looked at the
journal already and didn't
see anything that wasn't already in /var/log/messages, /var/log/mail
etc. Seems like a duplication of effort and a waste of space in
/var/log/journal. (which afaict can just be deleted).
It is significantly more powerful than traditional logging:
For example
journalctl /usr/bin/foo --> get messages from program foo
journalctl /dev/sda --> hard-drive problems ?
journalctl -p error --> only errors
If I can't look at the whole stream as a text
(messages, warnings,
etc), I don't get a field for what is right or wrong behavior and
certainly wouldn't be able to pick out an anomaly if I had to query
each item separately -- that global view is a good way to look for
'warts'...
I think I tried "journalctl" - without arguments you get the whole log
(afaict).
Currently it
is not a full replacement for syslog but I suggest you
to check it out.
I tend to use ngsyslog for the filtering benefits. -- really has some
powerful filtering in the 2.x line 
11:26
On Wednesday 19 September 2012, Per Jessen wrote:
Ditto - also much easier to configure than rsyslog.
--
Per Jessen, Zürich (12.4°C)
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Linda Walsh wrote:
Unfortunately you can do this only on machines where journalctl is
installed/available. I assume that you can't read the journald logs on
most existing systems.
Cristian Rodríguez wrote:
Same here.
El 15/09/12 11:49, Per Jessen escribió:
---
I assume the full power of linux's text utilities can be
used on them - like grep, sort, awk, perl... vim...
Having logs recorded in a non-text binary format tends to
make MS logs out-a-sight, out-a-mind, where as I often go and poke
around in /var/log and look to see if I notice anything 'new'. I do want to log, but I've looked at the
journal already and
didn't see anything that wasn't already in /var/log/messages,
/var/log/mail etc. Seems like a duplication of effort and a waste
of space in /var/log/journal. (which afaict can just be
deleted).
It is significantly more powerful than traditional logging:
For example
journalctl /usr/bin/foo --> get messages from program foo
journalctl /dev/sda --> hard-drive problems ?
journalctl -p error --> only errors If I can't look at the whole stream as a
text (messages, warnings,
etc), I don't get a field for what is right or wrong behavior and
certainly wouldn't be able to pick out an anomaly if I had to query
each item separately -- that global view is a good way to look for
'warts'...
I think I tried "journalctl" - without arguments you get the whole
log (afaict). Currently it is not a full replacement for syslog but
I suggest
you to check it out.
I tend to use ngsyslog for the filtering benefits. -- really has
some powerful filtering in the 2.x line
13:02
Ruediger Meier wrote:
On Wednesday 19 September 2012, Per Jessen wrote:
Unfortunately you can do this only on machines where journalctl is
installed/available. I assume that you can't read the journald logs on
most existing systems.
Hi Rudi
On 12.2, journalctl is called 'systemd-journalctl'.
--
Per Jessen, Zürich (11.9°C)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
If I can't look at the whole stream as a
text (messages, warnings,
etc), I don't get a field for what is right or wrong behavior and
certainly wouldn't be able to pick out an anomaly if I had to query
each item separately -- that global view is a good way to look for
'warts'...
I think I tried "journalctl" - without arguments you get the whole
log (afaict). 
15:20
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier <sweet_f_a(a)gmx.de> wrote:
Unfortunately you can do this only on machines where
journalctl is
installed/available. I assume that you can't read the journald logs on
most existing systems.
Just a matter of building journalctl from source I'd imagine, as would
be the case if you were missing grep.
I happen to agree that the binary format is unnecessary, but it also
happens to be a discretionary power of the author, and as soon as
there's a working and ubiquitous "journalctl" to parse it... and its
accompanying documentations... complaining will only start flame wars.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
16:49
El 19/09/12 11:20, Claudio Freire escribió:
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Or export them to text .. peraphs to json which is much more easy to
parse with automated tools...
Unfortunately you can do this only on machines
where journalctl is
installed/available. I assume that you can't read the journald logs on
most existing systems.
Just a matter of building journalctl from source I'd imagine, as would
be the case if you were missing grep. I happen to agree that the binary format is
unnecessary,
Ok, then how you implement all those features mentioned in the design
document to work fast ?
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
17:08
On Wed, Sep 19, 2012 at 12:49 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Wasn't the idea of binary formats to make it easy for tools to parse?
How does that line "parse" then? Export to text to make the
supposedly-very-machine-readable format easier to parse? Why not use
text from the beginning then?
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Just a matter
of building journalctl from source I'd imagine, as would
be the case if you were missing grep.
Or export them to text .. peraphs to json which is much more easy to
parse with automated tools...
17:09
El mié 19 sep 2012 13:08:17 CLST, Claudio Freire escribió:
On Wed, Sep 19, 2012 at 12:49 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Wasn't the idea of binary formats to make it easy for tools to parse?
How does that line "parse" then? Export to text to make the
supposedly-very-machine-readable format easier to parse? Why not use
text from the beginning then?
Please read the design document so you understand what we are talking
about here.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Just a
matter of building journalctl from source I'd imagine, as would
be the case if you were missing grep.
Or export them to text .. peraphs to json which is much more easy to
parse with automated tools...
17:14
On Wed, Sep 19, 2012 at 1:09 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Please read the design document so you understand what we are talking
about here.
Which one? This[0] one?
Doesn't say much.
[0] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLU…
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Or export them to text .. peraphs to json which is
much more easy to
parse with automated tools...
Wasn't the idea of binary formats to make it easy for tools to parse?
How does that line "parse" then? Export to text to make the
supposedly-very-machine-readable format easier to parse? Why not use
text from the beginning then? 
18:02
* Claudio Freire <klaussfreire(a)gmail.com> [2012-09-19 18:14]:
On Wed, Sep 19, 2012 at 1:09 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Please read the design document so you understand what we are talking
about here.
Which one? This[0] one?
Doesn't say much.
[0] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLU…
It's also full of FUD about supposed limitations of syslog since
it conveniently leaves out the advancements of modern syslog
implementations like rsyslog or syslog-ng which are mostly on-par
or superior in terms of features and functionality (well execept
the log sealing feature but that seems inherently racy and is
probably useless to those settings where log integrity is
important). I haven't seen any hard evidence of higher
performance of the "journal" compared to those syslog
implementations. So the "journal's" raison d'être pretty much
boild down to NIH.
BTW, tha fact that you can't turn this completely useless stuff
off is an execellent example of what is wrong with the new world
order you're buying in when switching to systemd (rather than
nebulous feeleings people have expressed here or the fact that
the boot process and ui differ from sysvinit).
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Or export them to text .. peraphs to json which is
much more easy to
parse with automated tools...
Wasn't the idea of binary formats to make it easy for tools to parse?
How does that line "parse" then? Export to text to make the
supposedly-very-machine-readable format easier to parse? Why not use
text from the beginning then?
18:45
El 19/09/12 14:02, Guido Berhoerster escribió:
BTW, tha fact that you can't turn this completely
useless stuff
off is an execellent example of what is wrong with the new world
order you're buying in when switching to systemd
It is called, making design descisions :-) and if you have sound
arguments against it please make them heard.
"Is binary", "is FUD", "I do not know how it works" are not
arguments,
but excuses.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
21:58
* Cristian Rodríguez <crrodriguez(a)opensuse.org> [2012-09-19 19:48]:
El 19/09/12 14:02, Guido Berhoerster escribió:
Well, it makes a logging solution mandatory which probably noone
would use based on technical merits over other implementations.
BTW, tha fact that you can't turn this
completely useless stuff
off is an execellent example of what is wrong with the new world
order you're buying in when switching to systemd
It is called, making design descisions :-) and if you have sound
arguments against it please make them heard. "Is binary", "is FUD", "I do
not know how it works" are not arguments,
but excuses.
The ignorance is only on your part, much of the FUD was refuted
when this "design document" was first published, check e.g. the
rsyslogd authors' blog, and even since then several functionality
gaps have been closed in both rsyslog and syslog-ng.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
23:07
Guido,
I'm not an expert in this, but I have one question and this is a one
time intervention... Can journald perform remote logs? That's all I
need.
NM
2012/9/19 Guido Berhoerster <gber(a)opensuse.org>rg>:
* Cristian Rodríguez <crrodriguez(a)opensuse.org>
[2012-09-19 19:48]:
--
---
Artigo 21 - Direito à Resistência
Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos,
liberdades e garantias e de repelir pela força qualquer agressão, quando não
seja possível recorrer à autoridade pública.
Constituição da Républica Portuguesa
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 19/09/12 14:02, Guido Berhoerster escribió:
Well, it makes a logging solution mandatory which probably noone
would use based on technical merits over other implementations.
BTW, tha fact that you can't turn this
completely useless stuff
off is an execellent example of what is wrong with the new world
order you're buying in when switching to systemd
It is called, making design descisions :-) and if you have sound
arguments against it please make them heard. "Is binary", "is FUD",
"I do not know how it works" are not arguments,
but excuses.
The ignorance is only on your part, much of the FUD was refuted
when this "design document" was first published, check e.g. the
rsyslogd authors' blog, and even since then several functionality
gaps have been closed in both rsyslog and syslog-ng.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
23:09
El 19/09/12 19:07, Nelson Marques escribió:
Guido,
I'm not an expert in this, but I have one question and this is a one
time intervention... Can journald perform remote logs? That's all I
need.
Not at the moment, as I have explained before, it is not still a full
replacment for syslog. there will be a network protocol with push/pull
abilitites.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
25 Sep
25 Sep
21:45
New subject: [opensuse-factory] systed/journald ! linux compat?
Cristian Rodríguez wrote:
.. Can journald perform remote logs? That's all I
----
Halt stop crash
!!!
I have to give up syslogng and all the filtering scripts I've written for it?
I need to redo all of system log filtering by filtering some arcane, non-unix
binary stream?
Sorry, that's not a unix utility. That needs to be fixed.
Can't it send it's messages to a pipe in text and any one of several log
deamons that have been developed over the years to hand logs, do their job?
Or are you saying this tool doesn't play nice with with existing linux tools
and tell everyone to "get a life and learn the window-ms way"?
Yeah -- I can dump a winlog in XML, -- it's a pain in the *** to parse.
I had to write a special perl prog just to count up error occurrences of
a program... on linux, it would have been a grep|wc.
I assume of course -- that the log entries will also stll hold to the unix
of 1-2 lines/message 1 if it can possibly do it (even overly long)??
I'm feeling a bit nervous about this -- like I'm gonna spend the next 5-7 years
learning a new windows-like interface -- with a service manager to control boot and
a binary log with awful filtering abilities...
That isn't unix/linux... MS has been trying to tell linux that their way is the
way of
the future for a long time... is this another way for them to get in the backdoor?
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
need.
Not at the moment, as I have explained before, it is not still a full
replacment for syslog. there will be a network protocol with push/pull
abilitites.
21:50
New subject: [opensuse-factory] Re: systed/journald ! linux compat?
El 25/09/12 17:45, Linda Walsh escribió:
I have to give up syslogng and all the filtering
scripts I've written
for it?
No! , simply installing syslog-ng will give you the exact functionality.
Can't it send it's messages to a pipe in
text and any one of several log
deamons that have been developed over the years to hand logs, do their job?
Yes it can, in a wide variety of ways.
That isn't unix/linux...
So be it.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
26 Sep
26 Sep
06:20
New subject: [opensuse-factory] systed/journald ! linux compat?
On 09/25/2012 10:45 PM, Linda Walsh wrote:
Cristian Rodríguez wrote:
.. Can journald perform remote logs? That's all I
----
Halt stop crash
!!!
I have to give up syslogng and all the filtering scripts I've written
for it?
No.
As I wrote in another thread a few days ago: you can safely "rm -fr
/var/log/journal" and use syslog-ng just as ever before (you don't need
to delete it, but it can save a few hundred megabytes of disk space...).
syslog-ng even detects if it runs under sysvinit or systemd, so there is
no need to rewrite the configuration file...
(I know, as I'm from the syslog-ng team, researched it, tested it, and
talked to systemd/journal developers in person about it)
Bye,
Peter Czanik (CzP)
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
need.
Not at the moment, as I have explained before, it is not still a full
replacment for syslog. there will be a network protocol with push/pull
abilitites.
07:00
New subject: [opensuse-factory] systed/journald ! linux compat?
Peter Czanik wrote:
On 09/25/2012 10:45 PM, Linda Walsh wrote:
I can confirm that it works just fine, I've been adjusting a couple of
my systems in the last week.
--
Per Jessen, Zürich (11.8°C)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Cristian Rodríguez wrote:
.. Can journald perform remote logs? That's all I
----
Halt stop crash
!!!
I have to give up syslogng and all the filtering scripts I've written
for it?
No.
As I wrote in another thread a few days ago: you can safely "rm -fr
/var/log/journal" and use syslog-ng just as ever before (you don't
need to delete it, but it can save a few hundred megabytes of disk
space...). syslog-ng even detects if it runs under sysvinit or
systemd, so there is no need to rewrite the configuration file...
(I know, as I'm from the syslog-ng team, researched it, tested it, and
talked to systemd/journal developers in person about it) need.
Not at the moment, as I have explained before, it is not still a
full replacment for syslog. there will be a network protocol with
push/pull abilitites.
14:03
New subject: [opensuse-factory] systed/journald ! linux compat?
On Wednesday 26 September 2012, Per Jessen wrote:
Peter Czanik wrote:
But what I understand is that syslog styled /var/log/messages shall be
removed per default? That's odd and will confuse many users and break a
lot of existing setups.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On 09/25/2012 10:45 PM, Linda Walsh wrote:
I can confirm that it works just fine, I've been adjusting a couple
of my systems in the last week.
Cristian Rodríguez wrote:
.. Can journald perform remote logs? That's all I
No.
As I wrote in another thread a few days ago: you can safely "rm -fr
/var/log/journal" and use syslog-ng just as ever before (you don't
need to delete it, but it can save a few hundred megabytes of disk
space...). syslog-ng even detects if it runs under sysvinit or
systemd, so there is no need to rewrite the configuration file...
(I know, as I'm from the syslog-ng team, researched it, tested it,
and talked to systemd/journal developers in person about it) > need.
Not at the moment, as I have explained before, it is not still a
full replacment for syslog. there will be a network protocol with
push/pull abilitites.
----
Halt stop crash
!!!
I have to give up syslogng and all the filtering scripts I've
written for it? 
14:08
New subject: [opensuse-factory] systed/journald ! linux compat?
Quoting Ruediger Meier <sweet_f_a(a)gmx.de>de>:
But what I understand is that syslog styled /var/log/messages shall be
removed per default? That's odd and will confuse many users and break a
lot of existing setups.
Not having /var/log/messages does not "break" anything, does it?
I can perfectly remove that file and my system keeps on running.
The only 'breakage' is documentation... which, of course, needs to be
adjusted to represent that.
Dominique
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
14:28
New subject: [opensuse-factory] systed/journald ! linux compat?
On Wednesday 26 September 2012, Dominique Leuenberger a.k.a DimStar
wrote:
Quoting Ruediger Meier <sweet_f_a(a)gmx.de>de>:
That's fine for you but there are a log of monitoring and security
robots which are configured to watch /var/log/messages. Many users have
advanced syslog setups running, so please don't remove syslog at least
in "zypper dup" case.
But what I understand is that syslog styled
/var/log/messages shall
be removed per default? That's odd and will confuse many users and
break a lot of existing setups.
Not having /var/log/messages does not "break" anything, does it?
I can perfectly remove that file and my system keeps on running. The only 'breakage' is documentation...
which, of course, needs to be
adjusted to represent that.
Dominique
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
14:37
New subject: [opensuse-factory] systed/journald ! linux compat?
On 26/09/12 10:28, Ruediger Meier wrote:
That's fine for you but there are a log of
monitoring and security
robots which are configured to watch /var/log/messages. Many users have
advanced syslog setups running, so please don't remove syslog at least
in "zypper dup" case.
huh ? Existing installations are not altered.. NEW installs will not
have syslog by default.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
14:51
New subject: [opensuse-factory] systed/journald ! linux compat?
On Wednesday 26 September 2012, Cristian Rodríguez wrote:
On 26/09/12 10:28, Ruediger Meier wrote:
That's nice to hear but was not clear to me in the light of recent
openSUSE development style where nobody seems to care about user's
existing systems.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That's fine for you but there are a log of
monitoring and security
robots which are configured to watch /var/log/messages. Many users
have advanced syslog setups running, so please don't remove syslog
at least in "zypper dup" case.
huh ? Existing installations are not altered.. NEW installs will not
have syslog by default.
14:37
New subject: [opensuse-factory] systed/journald ! linux compat?
Quoting Ruediger Meier <sweet_f_a(a)gmx.de>de>:
That's fine for you but there are a log of
monitoring and security
robots which are configured to watch /var/log/messages. Many users have
advanced syslog setups running, so please don't remove syslog at least
in "zypper dup" case.
That's probably not the 'standard user profile', but surely a valid
point; and as Peter pointed out often yet, syslog remains compatible
with systemd.
"zypper dup" might need to find a reasonable way of identifying if
you're a 'standard user' or 'advanced user': the pure presence of
/var/log/messages and/or syslog packages does not indicate anything
here (as all existing users have those... but only a fraction of "all
users" have setups as described by you).
Best regards,
Dominique
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
14:47
New subject: [opensuse-factory] systed/journald ! linux compat?
On Wednesday 26 September 2012, Dominique Leuenberger a.k.a DimStar
wrote:
Quoting Ruediger Meier <sweet_f_a(a)gmx.de>de>:
Please don't break setups for "only" a fracton of all users on purpose
for no good reason...
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That's fine for you but there are a log of
monitoring and security
robots which are configured to watch /var/log/messages. Many users
have advanced syslog setups running, so please don't remove syslog
at least in "zypper dup" case.
That's probably not the 'standard user profile', but surely a valid
point; and as Peter pointed out often yet, syslog remains compatible
with systemd.
"zypper dup" might need to find a reasonable way of identifying if
you're a 'standard user' or 'advanced user': the pure presence
of
/var/log/messages and/or syslog packages does not indicate anything
here (as all existing users have those... but only a fraction of "all
users" have setups as described by you). 
15:05
New subject: [opensuse-factory] systed/journald ! linux compat?
On Wednesday, September 26, 2012 15:28:24 Ruediger Meier wrote:
On Wednesday 26 September 2012, Dominique Leuenberger
a.k.a DimStar
wrote:
The proposal is to remove it from the default isntall, not from the
repos.
So, if you update, you'll keep syslog. If you do a new install, you
won't get it but can install it in addition...
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Quoting Ruediger Meier <sweet_f_a(a)gmx.de>de>:
That's fine for you but there are a log of monitoring and security
robots which are configured to watch /var/log/messages. Many users
have advanced syslog setups running, so please don't remove syslog at
least in "zypper dup" case. But what I understand is that syslog styled
/var/log/messages
shall
be removed per default? That's odd and will confuse many users and
break a lot of existing setups.
Not having /var/log/messages does not "break" anything, does it?
I can perfectly remove that file and my system keeps on running.
19 Sep
19 Sep
23:20
* Nelson Marques <nmo.marques(a)gmail.com> [2012-09-20 00:08]:
Guido,
I'm not an expert in this, but I have one question and this is a one
time intervention... Can journald perform remote logs? That's all I
need.
If you're talking about forwarding via TCP/UDP, then no, you
need a capable syslog implementation for that.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
23:44
2012/9/19 Guido Berhoerster <gber(a)opensuse.org>rg>:
* Nelson Marques <nmo.marques(a)gmail.com>
[2012-09-20 00:08]:
And we can have both working together? If so, there's no real harm :)
NM
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Guido,
I'm not an expert in this, but I have one question and this is a one
time intervention... Can journald perform remote logs? That's all I
need.
If you're talking about forwarding via TCP/UDP, then no, you
need a capable syslog implementation for that. 
20 Sep
20 Sep
14:04
Le mercredi 19 septembre 2012 à 23:44 +0100, Nelson Marques a écrit :
2012/9/19 Guido Berhoerster
<gber(a)opensuse.org>rg>:
Yes, you can.
For most purpose, only installing journal will be enough, IMHO. For
other "expert" features (like remote logging), a syslog implementation
should be used.
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
* Nelson Marques <nmo.marques(a)gmail.com>
[2012-09-20 00:08]:
And we can have both working together? If so, there's no real harm :) Guido,
I'm not an expert in this, but I have one question and this is a one
time intervention... Can journald perform remote logs? That's all I
need.
If you're talking about forwarding via TCP/UDP, then no, you
need a capable syslog implementation for that.
17:39
Frederic Crozat wrote:
Le mercredi 19 septembre 2012 à 23:44 +0100, Nelson
Marques a écrit :
What about the standard syslog setup that we use, does systemd journal
support that at the moment or will everything just be written to the
journal and then only filtered out when displayed?
This is perhaps not the right thread, but how functional is
systemd-journal really at the moment?
- where do I change the timestamp format?
- what are the fields that are mentioned in the man page?
- I was trying to get systemd-journal to show me what would normally go
into /var/log/firewall, how do I do that?
--
Per Jessen, Zürich (14.8°C)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
2012/9/19 Guido Berhoerster
<gber(a)opensuse.org>rg>:
Yes, you can.
For most purpose, only installing journal will be enough, IMHO. For
other "expert" features (like remote logging), a syslog implementation
should be used. * Nelson Marques <nmo.marques(a)gmail.com>
[2012-09-20 00:08]:
And we can have both working together? If so, there's no real harm :) Guido,
I'm not an expert in this, but I have one question and this is a
one time intervention... Can journald perform remote logs? That's
all I need.
If you're talking about forwarding via TCP/UDP, then no, you
need a capable syslog implementation for that.
17:43
El 20/09/12 13:39, Per Jessen escribió:
Looks like you have not understand the purpose of the journal and the
design descisions it has.
- where do I change the timestamp format?
You dont.
- what are the fields that are mentioned in the man
page?
http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html
- I was trying to get systemd-journal to show me what
would normally go
into /var/log/firewall, how do I do that?
You dont.
The whole purpose of the journal is to provide **structured logging** in
a single,consistent format.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
18:14
Cristian Rodríguez wrote:
Okay. Let me rephrase the question: How do I get output from the journal
with timestamps in the format I desire?
Thanks.
Okay, another rephrase: I want to see the messages logged by iptables
(in my firewall script). How do I do that?
--
Per Jessen, Zürich (13.8°C)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 20/09/12 13:39, Per Jessen escribió:
Looks like you have not understand the purpose of the journal and the
design descisions it has.
Certainly, I admit that. I am hoping somebody else will kindly enlighten
me.
- where do I
change the timestamp format?
You dont. - what are the
fields that are mentioned in the man page?
Http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html - I was trying
to get systemd-journal to show me what would normally
go into /var/log/firewall, how do I do that?
You dont.
The whole purpose of the journal is to provide **structured logging**
in a single,consistent format.
21 Sep
21 Sep
10:22
Le jeudi 20 septembre 2012 à 19:14 +0200, Per Jessen a écrit :
Cristian Rodríguez wrote:
Okay. Let me rephrase the question: How do I get output from the journal
with timestamps in the format I desire?
How about waiting for systemd 190 to land in Factory (probably next
week), which will have a much better journalctl (compared to the one we
have in 12.2) ?
El 20/09/12 13:39, Per Jessen escribió:
Looks like you have not understand the purpose of the journal and the
design descisions it has.
Certainly, I admit that. I am hoping somebody else will kindly enlighten
me.
- where
do I change the timestamp format?
You dont. Okay, another rephrase: I want to see the messages
logged by iptables
(in my firewall script). How do I do that?
Wait for systemd 189 (or later) + kernel 3.5 (or later), they will
support kernel structured logging in the journal.
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
20 Sep
20 Sep
18:15
On Thu, Sep 20, 2012 at 1:43 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
Well, that "purpose" is misguided.
Removing freedom from the user and, incidentally, the sysadmin, is
Windows' modus operandi, not Linux's. You won't be able to force that
down linux users' throats, because linux users use linux exactly
because of the freedom it provides.
The binary format already contains everything loggable, so the
customizable tool has to be journalctl.
Kind of journalctl --format="%t %h: blah"
That accomplishes journal's "purpose" without alienating users. Ie:
the tools that want to analyze logs can dictate output format.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
- where do I change the timestamp format?
You dont.
- I was trying to get systemd-journal to show me
what would normally go
into /var/log/firewall, how do I do that?
You dont.
The whole purpose of the journal is to provide **structured logging** in
a single,consistent format.
18:40
El 20/09/12 14:15, Claudio Freire escribió:
Well, that "purpose" is misguided.
No, it is not.
Removing freedom from the user and, incidentally, the
sysadmin, is
Windows' modus operandi, not Linux's. You won't be able to force that
down linux users' throats, because linux users use linux exactly
because of the freedom it provides.
Heh, "removing freedom".. ?
http://1cruzdelsur.files.wordpress.com/2011/09/mel-1995.jpg
lets repeat, unfortunately this does not seem to get across yet.. ***no
one is forcing you to use this distribution, or journald, or whatever **
please abandon victimhood, thanks !
The binary format already contains everything
loggable, so the
customizable tool has to be journalctl.
Kind of journalctl --format="%t %h: blah"
That accomplishes journal's "purpose" without alienating users. Ie:
the tools that want to analyze logs can dictate output format.
It could , yes. however that is not implemented. you could though write
a very small script to obtain that result in a few minutes though, just
use the --output switch with value "json" and process accordingly.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
18:45
On Thu, Sep 20, 2012 at 2:40 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
I guess I could do that. But that's because I'm a programmer, not all
sysadmins are.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
The binary
format already contains everything loggable, so the
customizable tool has to be journalctl.
Kind of journalctl --format="%t %h: blah"
That accomplishes journal's "purpose" without alienating users. Ie:
the tools that want to analyze logs can dictate output format.
It could , yes. however that is not implemented. you could though write
a very small script to obtain that result in a few minutes though, just
use the --output switch with value "json" and process accordingly.
18:50
On Thu, Sep 20, 2012 at 2:40 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
lets repeat, unfortunately this does not seem to get across yet.. ***no
one is forcing you to use this distribution, or journald, or whatever **
please abandon victimhood, thanks !
Well.... because that's a lame answer not worth considering.
I'm an administrator and lead developer on a few projects, and I can
tell you, I don't work to increase the amount of disk usage on
SourceForge or to cater to the needs of a very few people I like...
the more my project's used, the better I feel. In essence, opensource
projects strive, usually, to be useful for as many as possible and
manageable.
So you can't tell me "nobody's forcing you to use this distro",
because... well... this distro isn't being maintained so that only OBS
can use it. It's for *general* use, and it has to cater to *general*
needs and public.
Last I checked, openSUSE was good for both, desktop, laptop and
server. If you want to drop some of those explicitly, that would have
to be announced. It hasn't, or at least I didn't see the announcement.
Right now, in this particular point, we're talking about server
(sysadmins tend to manage servers, but that's not always true).
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
19:25
Claudio Freire wrote:
On Thu, Sep 20, 2012 at 2:40 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
+1. I'm amazed at the complete disrespect for the openSUSE users
though.
--
Per Jessen, Zürich (11.3°C)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
lets repeat, unfortunately this does not seem to get across yet..
***no one is forcing you to use this distribution, or journald, or
whatever ** please abandon victimhood, thanks !
Well.... because that's a lame answer not worth considering.
20:51
Hello,
Before we all end up in flames, a hopefully not too biased view from
syslog-ng upstream :-)
First of all, systemd journal is a perfect solution for about 90%+ of
openSUSE users, which have stand alone workstations and don't care at
all about logging. They don't need rsyslog or syslog-ng. The journal
collects logs under /var/log/journal into some binary files. By default
it does not take more than 5% of available disk space, so logs can't
fill up the partition accidentally. It's very limited, but user friendly.
Actually I don't really understand, why syslog is still installed on
openSUSE (ArchLinux removed syslog from systemd based installations to
avoid dual logging...), but this is a different questions...
For the remaining <10%, see some information below.
On 09/20/2012 06:39 PM, Per Jessen wrote:
What about the standard syslog setup that we use, does
systemd journal
support that at the moment or will everything just be written to the
journal and then only filtered out when displayed?
The good news is, that standard
syslog setup is supported. One can
almost completely get rid of systemd journal. Just "rm -fr
/var/log/journal". It's safe, systemd journal will still keep enough
information in tmpfs to provide information about running services. It
still takes over /dev/log, but forwards all information to
/var/run/systemd/journal/syslog so syslog-ng can read local logs from
there instead of /dev/log.
The bad news is, that this info is not mentioned in any man pages
installed on openSUSE.
So, if you still want a flexible logging solution, like syslog-ng, on a
server, or a networked workstation, just do that "rm -fr
/var/log/journal". This way even that 5% of the partition is not wasted,
and you can configure your favorite logger to your liking. You will have
all the usual formatting templates, networking possibilities, filters,
patterndb, etc.
I hope this helps, and flames are extinguished :)
Bye,
Peter Czanik (CzP)
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
21:06
On Thu, Sep 20, 2012 at 4:51 PM, Peter Czanik <pczanik(a)fang.fa.gau.hu> wrote:
Before we all end up in flames, a hopefully not too
biased view from
syslog-ng upstream :-)
Yep, sorry about that. I was prodded and reacted before I noticed.
First of all, systemd journal is a perfect solution
for about 90%+ of
openSUSE users, which have stand alone workstations and don't care at all
about logging. They don't need rsyslog or syslog-ng. The journal collects
logs under /var/log/journal into some binary files. By default it does not
take more than 5% of available disk space, so logs can't fill up the
partition accidentally. It's very limited, but user friendly.
Actually I don't really understand, why syslog is still installed on
openSUSE (ArchLinux removed syslog from systemd based installations to avoid
dual logging...), but this is a different questions...
Strangely enough, I agree. I complain about the binary log because
it's unnecessary complexity and obscurity, but the fact that
workstation users rarely need to bother reading the logs kind of
dilutes the effects of all that, and the fact that syslog is still
functional in openSUSE is a very very good thing for those that do.
Having it run, by default, in tandem with journal was, AFAIK, a
transitional measure. Because all init stuff goes into the journal,
and users new to systemd won't know where to find all those messages
and be unable to fix boot problems. Now, systemd is fixing the tty
"bug" that made it not show those messages to the console, meaning
users will *see* what's wrong, and syslog will cease to be useful in
the default installation.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
23 Sep
23 Sep
16:34
Claudio Freire wrote:
On Thu, Sep 20, 2012 at 4:51 PM, Peter Czanik
<pczanik(a)fang.fa.gau.hu>
wrote:
Leaving out syslog from the standard pattern(s) just means more work for
those of us with more than a single workstation. I am slowly beginning
to see the necessity of using autoyast (to maintain my own standard
installation pattern).
--
Per Jessen, Zürich (19.9°C)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Before we all end up in flames, a hopefully not
too biased view from
syslog-ng upstream :-)
Yep, sorry about that. I was prodded and reacted before I noticed.
First of all, systemd journal is a perfect
solution for about 90%+ of
openSUSE users, which have stand alone workstations and don't care at
all about logging. They don't need rsyslog or syslog-ng. The journal
collects logs under /var/log/journal into some binary files. By
default it does not take more than 5% of available disk space, so
logs can't fill up the partition accidentally. It's very limited, but
user friendly. Actually I don't really understand, why syslog is
still installed on openSUSE (ArchLinux removed syslog from systemd
based installations to avoid dual logging...), but this is a
different questions...
Strangely enough, I agree. I complain about the binary log because
it's unnecessary complexity and obscurity, but the fact that
workstation users rarely need to bother reading the logs kind of
dilutes the effects of all that, and the fact that syslog is still
functional in openSUSE is a very very good thing for those that do.
18:12
On Sun, Sep 23, 2012 at 12:34 PM, Per Jessen <per(a)computer.org> wrote:
Leaving out syslog from the standard pattern(s) just
means more work for
those of us with more than a single workstation. I am slowly beginning
to see the necessity of using autoyast (to maintain my own standard
installation pattern).
That's a good idea regardless of journal and systemd anyway.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
25 Sep
25 Sep
10:42
On Thursday, September 20, 2012 21:51:35 Peter Czanik wrote:
Hello,
Before we all end up in flames, a hopefully not too biased view from
syslog-ng upstream :-)
First of all, systemd journal is a perfect solution for about 90%+ of
openSUSE users, which have stand alone workstations and don't care at
all about logging. They don't need rsyslog or syslog-ng. The journal
collects logs under /var/log/journal into some binary files. By
default it does not take more than 5% of available disk space, so
logs can't fill up the partition accidentally. It's very limited, but
user friendly. Actually I don't really understand, why syslog is
still installed on openSUSE (ArchLinux removed syslog from systemd
based installations to avoid dual logging...), but this is a
different questions...
Thanks Peter for the info. So, let's remove syslog/rsyslog from the
default install now.
Coolo, could you do the change - if you agree with it, please?
Frederic, could you send Karl Eichwalder an update for the 12.3 release
notes mentioning this?
Thanks,
Andreas
For the remaining <10%, see some information
below.
On 09/20/2012 06:39 PM, Per Jessen wrote:
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
What about the standard syslog setup that we use,
does systemd
journal support that at the moment or will everything just be
written to the journal and then only filtered out when displayed?
The good news is, that standard syslog setup is supported. One can
almost completely get rid of systemd journal. Just "rm -fr
/var/log/journal". It's safe, systemd journal will still keep enough
information in tmpfs to provide information about running services. It
still takes over /dev/log, but forwards all information to
/var/run/systemd/journal/syslog so syslog-ng can read local logs from
there instead of /dev/log.
The bad news is, that this info is not mentioned in any man pages
installed on openSUSE.
So, if you still want a flexible logging solution, like syslog-ng, on
a server, or a networked workstation, just do that "rm -fr
/var/log/journal". This way even that 5% of the partition is not
wasted, and you can configure your favorite logger to your liking.
You will have all the usual formatting templates, networking
possibilities, filters, patterndb, etc.
I hope this helps, and flames are extinguished :)
Bye,
Peter Czanik (CzP)
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/ 
11:39
On 25.09.2012 11:42, Andreas Jaeger wrote:
On Thursday, September 20, 2012 21:51:35 Peter Czanik
wrote:
So this kind of puts the last nail in the sysvinit coffin?
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hello,
Before we all end up in flames, a hopefully not too biased view from
syslog-ng upstream :-)
First of all, systemd journal is a perfect solution for about 90%+ of
openSUSE users, which have stand alone workstations and don't care at
all about logging. They don't need rsyslog or syslog-ng. The journal
collects logs under /var/log/journal into some binary files. By
default it does not take more than 5% of available disk space, so
logs can't fill up the partition accidentally. It's very limited, but
user friendly. Actually I don't really understand, why syslog is
still installed on openSUSE (ArchLinux removed syslog from systemd
based installations to avoid dual logging...), but this is a
different questions...
Thanks Peter for the info. So, let's remove syslog/rsyslog from the
default install now.
Coolo, could you do the change - if you agree with it, please?
11:46
On Tuesday, September 25, 2012 12:39:59 Stephan Kulow wrote:
On 25.09.2012 11:42, Andreas Jaeger wrote:
Ah, you're right - let's do it one by one and not start from the end.
Frederic, what steps do you propose - here's my suggestion:
1. update to systemd 185
2. Change grub to not offer switch for init packages
3. Change sysvinit-init package (or however it's called)
4. Remove syslog from default install.
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Thursday, September 20, 2012 21:51:35 Peter
Czanik wrote:
So this kind of puts the last nail in the sysvinit coffin? Hello,
Before we all end up in flames, a hopefully not too biased view
from
syslog-ng upstream :-)
First of all, systemd journal is a perfect solution for about 90%+
of
openSUSE users, which have stand alone workstations and don't care
at
all about logging. They don't need rsyslog or syslog-ng. The
journal
collects logs under /var/log/journal into some binary files. By
default it does not take more than 5% of available disk space, so
logs can't fill up the partition accidentally. It's very limited,
but
user friendly. Actually I don't really understand, why syslog is
still installed on openSUSE (ArchLinux removed syslog from systemd
based installations to avoid dual logging...), but this is a
different questions...
Thanks Peter for the info. So, let's remove syslog/rsyslog from the
default install now.
Coolo, could you do the change - if you agree with it, please?
20 Sep
20 Sep
15:36
* Nelson Marques <nmo.marques(a)gmail.com> [2012-09-20 00:44]:
2012/9/19 Guido Berhoerster
<gber(a)opensuse.org>rg>:
Rather side by side, so be sure to disable logging to
/var/log/journal or it'll take twice the space.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
* Nelson Marques <nmo.marques(a)gmail.com>
[2012-09-20 00:08]:
And we can have both working together? If so, there's no real harm :) Guido,
I'm not an expert in this, but I have one question and this is a one
time intervention... Can journald perform remote logs? That's all I
need.
If you're talking about forwarding via TCP/UDP, then no, you
need a capable syslog implementation for that.
19 Sep
19 Sep
23:18
El 19/09/12 17:58, Guido Berhoerster escribió:
The ignorance is only on your part, much of the FUD
was refuted
when this "design document" was first published,
The misconceptions and obvious bias from that article has been already
addressed.
Let's see what of the competing solutions get adopted and goes forward,
good luck with that, though.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
18:06
On Wed, Sep 19, 2012 at 12:49 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
So, quoting the doc:
I happen to agree that the binary format is
unnecessary,
Ok, then how you implement all those features mentioned in the design
document to work fast ? Simplicity: little code with few dependencies and
minimal waste through abstraction.
Text files are as simple as it gets.
Zero Maintenance: logging is crucial functionality
to debug and monitor systems, as such it should not be a problem source of its own, and
work as well as it can even in dire circumstances. For example, that means the system
needs to react gracefully to problems such as limited disk space or /var not being
available, and avoid triggering disk space problems on its own (e.g. by implementing
journal file rotation right in the daemon at the time a journal file is extended).
Nothing to do with text files or not, it's an implementation issue.
Robustness: data files generated by the journal
should be directly accessible to administrators and be useful when copied to different
hosts with tools like “scp” or “rsync”. Incomplete copies should be processed gracefully.
Journal file browsing clients should work without the journal daemon being around.
Text files provide this natively
Portable: journal files should be usable across
the full range of Linux systems, regardless which CPU or endianess is used. Journal files
generated on an embedded ARM system should be viewable on an x86 desktop, as if it had
been generated locally.
ASCII text is the epitome of portability. Use UTF-8 if you need
unicode support. In any case, highly portable.
Performance: journal operations for appending and
browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in
order to provide for organization-wide log monitoring with good performance
Appending is O(1) (assuming constant line length) on text files. If
browsing means reading the first, second, third etc entries sorted by
time, then browsing is also O(1) in text files. If browsing means
reading the entry at time X (for arbitrary time X), then it's O(log n)
in text files by means of bisection, as text-based logs are naturally
sorted by timestamp.
If you need to search by other fields, you need indices. This can be
done with text files, but syslog-ng already supports a better way:
just dump everything into a (pattern) database as it comes. In any
case, if you introduce indices, appending is no longer O(1).
Integration: the journal should be closely
integrated with the rest of the system, so that logging is so basic for a service, that it
would need to opt-out of it in order to avoid it. Logging is a core responsibility for a
service manager, and it should be integrated with it reflecting that.
Again, has nothing to do with text or not.
Minimal Footprint: journal data files should be
small in disk size, especially in the light that the amount of data generated might be
substantially bigger than on classic syslog.
While text files have a tendency to include some bloat, both because
of the format and because of the verbose nature of human-readable
messages, data compression can easily compensate those redundancies,
and it has been the mainstream for logging for ages. The fact that
compression happens at log rotation does not detract from its
effectiveness, and some compression schemes are even random-readable
(think bzip2). Other compression schemes are packetizable (deflate),
making them suitable for record-by-record on-the-fly compression.
Compressed formats are technically binary, but in practice, due to the
ubiquity and transparency of decompression tools, rather equivalent to
text files. You can even zless and zgrep.
General Purpose Event Storage: the journal should
be useful to store any kind of journal entry, regardless of its format, its meta data or
size.
Text files can contain arbitrary data, so there's nothing more
general-purpose than text files. If you need binary blobs, you have
various codings that will result in ASCII-safe text representing it.
Just to mention two, hex and base-64.
Unification: the numerous different logging
technologies should be unified so that all loggable events end up in the same data store,
so that global context of the journal entries is stored and available later. e.g. a
firmware entry is often followed by a kernel entry, and ultimately a userspace entry. It
is key that the relation between the three is not lost when stored on disk.
Base for Higher Level Tools: the journal should provide a generally useful API which
can be used by health monitors, recovery tools, crash report generators and other higher
level tools to access the logged journal data.
Universality: as a basic building block of the OS the journal should be universal
enough and extensible to cater for application-specific needs. The format needs to be
extensible, and APIs need to be available.
Clustering & Network: Today computers seldom work in isolation. It is crucial
that logging caters for that and journal files and utilities are from the ground on
developed to support big multi-host installations.
Unrelated to store format. "Data store" here can easily be a series of
text files.
Scalability: the same way as Linux scales from
embedded machines to super computers and clusters, the journal should scale, too. Logging
is key when developing embedded devices, and also essential at the other end of the
spectrum, for maintaining clusters. The journal needs to focus on generalizing the common
use patterns while catering for the specific differences, and staying minimal in
footprint.
Again, no reason why text files can't scale. There's no need to stuff
everything into a single text file, and abstraction APIs can easily
query several text files in tandem. Text-vs-binary provides no
features in this regard.
Security: Journal files should be authenticated to
make undetected manipulation impossible.
Text-based log lines can also be authenticated.You have MACs, PGP
ASCII armor, etc...
Even assuming MACs on both implementations, I seriously doubt journal
files are safer from tampering by root, though, leaving it in the same
situation as syslog is. If root can create a log file, root can tamper
with it.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
30 Apr
30 Apr
07:46
Am 19.09.2012 17:49, schrieb Cristian Rodríguez:
I give a sh*t on that design document, as long as I can not read my
logs, it is the end of the month and they would be very useful to do my
accounting.
Fun facts about sytemd-journal:
* it logs to a binary database
* it can not filter out the user session logs from the system logs
* if the database is broken, i tells you (journalctl --verify)
* but it can not repair or recover it
* even if the database is not broken, it can not read it (bnc#817778)
* fills the disk way beyound its configured limits (bnc#817780)
...well, only "fun" if you have a strange definition of "fun".
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 19/09/12 11:20, Claudio Freire escribió:
Unfortunately, there is no tool to read or export the BLOB put onto my
disk and fragmenting my filesystem like hell, see
https://bugzilla.novell.com/817778
Yay. Never had that with text logs. Maybe they were missing a few lines
after a crash, or they had some kB of binary garbage interspersed, but I
could always read them.
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Or export them to text .. peraphs to json which is much more easy to
parse with automated tools... Unfortunately you can do this only on machines
where journalctl is
installed/available. I assume that you can't read the journald logs on
most existing systems.
Just a matter of building journalctl from source I'd imagine, as would
be the case if you were missing grep. I happen to
agree that the binary format is unnecessary,
Ok, then how you implement all those features mentioned in the design
document to work fast ?
08:23
* Stefan Seyfried <stefan.seyfried(a)googlemail.com> [2013-04-30 08:46]:
Am 19.09.2012 17:49, schrieb Cristian Rodríguez:
I give a sh*t on that design document, as long as I can not read my
logs, it is the end of the month and they would be very useful to do my
accounting.
Fun facts about sytemd-journal:
* it logs to a binary database
* it can not filter out the user session logs from the system logs
* if the database is broken, i tells you (journalctl --verify)
* but it can not repair or recover it
* even if the database is not broken, it can not read it (bnc#817778)
* fills the disk way beyound its configured limits (bnc#817780)
...well, only "fun" if you have a strange definition of "fun".
That's probably the reason why no other distro has chosen to rely
on it exclusively (not even Fedora!), so the oS userbase doing
beta-testing. It should probably be noted in the release notes
that users who rely on logs (and/or have significant amounts of
log messages) should install rsyslog.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 19/09/12 11:20, Claudio Freire escribió:
Unfortunately, there is no tool to read or export the BLOB put onto my
disk and fragmenting my filesystem like hell, see
https://bugzilla.novell.com/817778
Yay. Never had that with text logs. Maybe they were missing a few lines
after a crash, or they had some kB of binary garbage interspersed, but I
could always read them.
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Or export them to text .. peraphs to json which is much more easy to
parse with automated tools... Unfortunately you can do this only on machines
where journalctl is
installed/available. I assume that you can't read the journald logs on
most existing systems.
Just a matter of building journalctl from source I'd imagine, as would
be the case if you were missing grep. I happen
to agree that the binary format is unnecessary,
Ok, then how you implement all those features mentioned in the design
document to work fast ?
09:02
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
I give a sh*t on that design document, as long as I
can not read my
logs, it is the end of the month and they would be very useful to do my
accounting.
Fun facts about sytemd-journal:
* it logs to a binary database
Yes.
* it can not filter out the user session logs from the
system logs
Something can be done about that..I thought it was able to so
* if the database is broken, i tells you (journalctl
--verify)
* but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
* even if the database is not broken, it can not read
it (bnc#817778)
Yes, it can be slow, anyway that looks more like a bug.
* fills the disk way beyound its configured limits
(bnc#817780)
"the journald states in the logs:
"Allowing runtime journal files to grow to 394.8M."
but:
susi:~ # journalctl --disk-usage
Journals take up 501.9M on disk.
epic fail :-) "
Yes, epic fail of **your understanding** of the message you are seeing.
It says "Allowing **runtime** journal files" .. "runtime journal
files"
are those living in /run not the ones living in /var/log/journal.
journalctl --disk-usage accounts for total size of runtime+ system.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
10:38
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
How can such untested alpha quality stuff make it into a distro?
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
I give a sh*t on that design document, as long as
I can not read my
logs, it is the end of the month and they would be very useful to
do my accounting.
Fun facts about sytemd-journal:
* it logs to a binary database
Yes.
* it can not filter out the user session logs
from the system logs
Something can be done about that..I thought it was able to so
* if the database is broken, i tells you
(journalctl --verify)
* but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either) 
11:21
On 2013-04-30T11:38:19, Ruediger Meier <sweet_f_a(a)gmx.de> wrote:
Because the community didn't object when it was merged, or during the
beta phase.
Regards,
Lars
--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG
Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That's
why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
How can such untested alpha quality stuff
make it into a distro?
11:58
Am 30.04.2013 12:21, schrieb Lars Marowsky-Bree:
On 2013-04-30T11:38:19, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Because the community didn't object when it was merged, or during the
beta phase.
If I did not know that you are not taking drugs, I would now wonder
which one is adjusting your view of the reality :-)
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
How can such untested alpha quality stuff
make it into a distro? 
13:18
Hay, I am in danger of doing a Linus here ... As he so often says "the
kernel WILL not break user space", and so Distributions MUST not (a)
break users, (b) fail to test properly, themselves, (c) Passively
accept the latest crap.
If they do accept crap they reinforce the vicious circle of Projects
shipping barely alpha code as 'finished'. It tool me minutes to
conclude Kmail2 was a stinking pile of manure, a day to decide that
regressing to Kmail1 would be unnecessarily difficult and a morning to
get Claws Mail working, including fixing Mdir mailboxes.
The next time I will dump all KDE.
Cheers, omb
Am Tue, 30 Apr 2013 12:58:20 +0200, scheib Stefan
Seyfried:
Am 30.04.2013 12:21, schrieb Lars Marowsky-Bree:
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On 2013-04-30T11:38:19, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Because the community didn't object when it was merged, or during the
beta phase.
If I did not know that you are not taking drugs, I would now wonder
which one is adjusting your view of the reality :-)
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That's why it is called --verify and not --repair .. (not
implemented yet, never advertised as repair either)
How can such untested alpha
quality stuff make it into a distro? 
1 May
1 May
02:04
Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Because the community didn't object when it was merged, or during the
beta phase.
Oh, many of us objected, but were ignored. In fact, look at
Christian's reaction to Stefan's bug report -- no comment needed,
denial at its best.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jschrod(a)acm.org
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
How can such untested alpha quality stuff
make it into a distro?
02:36
El 30/04/13 21:04, Joachim Schrod escribió:
Lars Marowsky-Bree wrote:
Objecting does not mean anything, those who do the work are the ones
that take decisions.
In fact, look at
On 2013-04-30T11:38:19, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Because the community didn't object when it was merged, or during the
beta phase.
Oh, many of us objected, but were ignored.
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
How can such untested alpha quality stuff
make it into a distro? Christian's reaction to Stefan's bug report
-- no comment needed,
denial at its best.
What denial ? He pointed out 3 problems,
- one bogus based on the a misunderstading on what "runtime journal
files" mean.
- The other one is where he says --verify does not fix broken journal
files, this is expected, it has never gained the capability of fixing
the files nor it was advertised that it did, what the command line flags
do is clearly documented in the manual.
- The other problem he mentioned I told it was a bug.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
02:59
Cristian Rodríguez wrote:
El 30/04/13 21:04, Joachim Schrod escribió:
Yes, that's the bad thing -- I accept that I'm not as relevant as
I'm to busy looking for the next TeX-Live that must go out and CTAN
must stay running, but -- can't you folks take some hints from
Linus that backward compatibility and robustness is a MUST HAVE,
not a NICE to HAVE thing?
Lars Marowsky-Bree wrote:
Objecting does not mean anything, those who do the work are the
ones that take decisions. On 2013-04-30T11:38:19, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Oh, many of us objected, but were ignored. > That's why it is called --verify and not
--repair .. (not
> implemented
> yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or
during the
beta phase. In fact, look at
That's the denial I meant. That something is documented in the
manual doesn't mean that it ain't a bug, and a show-stopper for
putting things in a distribution, even though some folks like to
think it is.
Don't understand me wrong -- I think systemd has a lot of good
ideas and a sound concept. The introduction in oS was too rushed,
and its tendency to subsume all other system service are
frightening from a sysadmin maintenance perspective.
I've read your joke yesterday about CUPS not being subsumed by
systemd right yet -- but I wouldn't hold my breath for it. crond is
next [*], what comes afterwards? Are you sure that printers are not
something that might appear and disappear and thus something that
systemd developers might want to start to their we-control-it list?
Since, that's the pattern -- ``everything that might come up or go
down asynchronously has to be managed by systemd'' (TM).
For developer's laptops, that's nice, but on servers the current
state of affair is not adequate.
Joachim
[*] Note: My problem ain't because systemd is not able to issue
time-event based activations. It's clear that it is. It's because
cron is already completely inadequate for any professional job
scheduling tasks -- and systemd is worse, instead of being better.
The actual problem is decoupling: substitution of cron jobs in a
given distribution seems to be easier than decoupling from the
integration that's planned for systemd as a cron replacement. Well,
we'll see how that turns out;
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jschrod(a)acm.org
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Christian's reaction to Stefan's bug
report -- no comment needed,
denial at its best.
What denial ? He pointed out 3 problems,
- The other one is where he says --verify does not fix broken
journal files, this is expected, it has never gained the capability
of fixing the files nor it was advertised that it did, what the
command line flags do is clearly documented in the manual.
03:30
El 30/04/13 21:59, Joachim Schrod escribió:
That's the denial I meant. That something is
documented in the
manual doesn't mean that it ain't a bug, and a show-stopper for
putting things in a distribution, even though some folks like to
think it is.
There is no bug, what is happening here is that a the feature required
to "fsck" the journal files has not been implemented yet.
I've read your joke yesterday about CUPS not
being subsumed by
systemd right yet -- but I wouldn't hold my breath for it.crond is
next [*],
No, again you did not understood what I said. (I am expressing myself
bad maybe?) what I said was that there will be no wrapper or otherwise
an intervention in cron or the at daemon in the systemd side at all.
people will be able to run cron or at without any change whatsoever.
But we may migrate the cron scripts shipped with the distribution to
native systemd timers (at some point in the future) and thus making cron
unnecessary as a default component.
what comes afterwards?
Here is the list http://cgit.freedesktop.org/systemd/systemd/tree/TODO
of things that come in the systemd side, there is no intention of
replacing any other major component.(apart from getting the DBUS
protocol support in the kernel and making systemd use it to drop the
circular dependency between dbus and systemd, Greg KH is working on
that, so I am confident it will go OK)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
05:17
On Tue, 30 Apr 2013 22:30:26 -0400
Cristian Rodríguez <crrodriguez(a)opensuse.org> wrote:
There is no bug, what is happening here is that a the
feature
required to "fsck" the journal files has not been implemented yet.
With frequency of difficulties it has to actually do logging, not
implemented repair facility has the same effect as a bug.
(And, I am one of annoyed users now. You know problems with
imperfections of journalctrl.)
--
Regards, Rajko.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
10:10
Am 01.05.2013 04:30, schrieb Cristian Rodríguez:
El 30/04/13 21:59, Joachim Schrod escribió:
The fun thing is, that exactly the thing happened that journal critics
had foreseen and which were dismissed as "will not happen" by systemd
upstream.
* binary format with no tool to read or fix it in case of the slightest
problem.
All the proposed goodness of the journal is totally useless if you
cannot read the logs.
If I have a few bytes of garbage in a journal file, it is toast. With
the default of one file being 256MB in size (my root partition is 20GB),
this will amount to > 3 months of logs lost.
With traditional logging, a few bytes of garbage in the logfile will be
exactly that: a few bytes of garbage. Nobody will care. I can still
extract everything.
It is the old problem of data protection vs. data security. The data in
the journal is well protected. Protected from getting used by me.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That's the denial I meant. That something is
documented in the
manual doesn't mean that it ain't a bug, and a show-stopper for
putting things in a distribution, even though some folks like to
think it is.
There is no bug, what is happening here is that a the feature required
to "fsck" the journal files has not been implemented yet.
15:08
On Wed, 01 May 2013 11:10:32 +0200
Stefan Seyfried <stefan.seyfried(a)googlemail.com> wrote:
With traditional logging, a few bytes of garbage in
the logfile will
be exactly that: a few bytes of garbage. Nobody will care. I can still
extract everything.
Nobody will care only if log presence is important only to troubleshoot
technical problems, but usually it will raise a flag about possibility
that someone else fiddled with logs, which is not a good sign.
I looked for more debugging information in journal (12.2), so when I
stumbled over missing entries before certain time, I spent some time
looking at the system using Live USB. Why? Because I wasn't sure what
happened. Problem with logging can be a bug (which is harmless), or
sign that somebody cracked the system.
I found out that journal had 2 log files covering all the time from
installation to present, but it was ignoring presence of older file and
nothing will tell me that there is another log. This is probably yet
another not implemented functionality, at least in 12.2.
What is annoying from my prospective is that almost everyone is
learning systemd and journal and udev (and hopefully nothing more),
and availability of user to user help is sparse at best. When you are
stuck with a problem, you are on your own most of the time, which
grants days of fun, for those that have no other ways to have it.
When you have problem with 12.2, which has older version of systemd and
journald, you are on your own as those that know the best (Frederic
and Cristian) have very little interest to help with stuff that is
solved in a newer version, and on the other side, there is no new
systemd port to 12.2. Frederic mentioned that changes are too intrusive
to create port, which tells me that two systemd versions are not
backwards compatible and he will have to spend too much time
redesigning 12.2.
While I like to solve technical puzzles, amount that is now pushed on
users like me is overwhelming and I look for other areas that need
help to contribute to openSUSE for time being, ie. until number
of changes in certain time frame subside.
--
Regards, Rajko.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
17:43
El 01/05/13 10:08, Rajko escribió:
I found out that journal had 2 log files covering all
the time from
installation to present, but it was ignoring presence of older file and
nothing will tell me that there is another log. This is probably yet
another not implemented functionality, at least in 12.2.
This was fixed in systemd 201 and backported to 12.3
which tells me that two systemd versions are not
backwards compatible and he will have to spend too much time
redesigning 12.2.
It is not backward compatible in the same sense kernel 3.0 is not source
compatible with 3.9, backward compatibility is there for the interfaces
that are exposed to the user or callers, not internal ones on which all
SUSE specific additions depend on.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
4 May
4 May
23:50
Rajko wrote:
On Wed, 01 May 2013 11:10:32 +0200
Stefan Seyfried <stefan.seyfried(a)googlemail.com> wrote:
---
Not at all -- it is FAR more likely that the logging daemon didn't
shut down the log properly and garbage got put there. HW & SW malfunctions
are far more likely to be the cause of something than tampering.
Regardless, w/text logs there is nothing preventing you from recovering
the undamaged portions, but conversely, you are raising the issue
of how easy it is for a hacker to cover their tracks -- just a
few bytes in the log and it is corrupt and can't be recovered.
You think that is better?
There are no benefits of binary logs to system owners, but
there is large benefit for those who want to easily cover their tracks.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
With traditional logging, a few bytes of garbage
in the logfile will
be exactly that: a few bytes of garbage. Nobody will care. I can still
extract everything.
Nobody will care only if log presence is important only to troubleshoot
technical problems, but usually it will raise a flag about possibility
that someone else fiddled with logs, 
1 May
1 May
03:11
On 04/30/2013 09:36 PM, Cristian Rodríguez pecked at the keyboard and wrote:
El 30/04/13 21:04, Joachim Schrod escribió:
And here I thought this was a community distro, but I see it's more of a
dictatorship. :-)
--
Ken Schneider
SuSe since Version 5.2, June 1998
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Lars Marowsky-Bree wrote:
Objecting does not mean anything, those who do the work are the ones
that take decisions.
On 2013-04-30T11:38:19, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Oh, many of us objected, but were ignored. > That's why it is called --verify and not
--repair .. (not implemented
> yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the
beta phase.
03:33
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
And here I thought this was a community distro, but I
see it's more of a
dictatorship. :-)
It is more a DOocracy that a dictatorship.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
03:57
On 04/30/2013 10:33 PM, Cristian Rodríguez pecked at the keyboard and wrote:
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
I see, DO it my way or go elsewhere.
My final comments:
openSUSE a.k.a. SuSE used to be one of the most stable distros
available. Of late many apps have been forced on the users that were
*clearly* pre-alpha. I don't remember the releases but the first major
fuckup was zypper (or it's backend) that clearly was forced out before
it was ready. The next I recall was KDE4 that was clearly pre-alpha when
made the default install version. And now systemd has been forced on the
masses even though it is not production ready. And this is the point,
many sys admins use openSUSE on production servers. Why? Because in the
past it was *that* stable. Nowadays not so much. Who in their right mind
can risk running a server without boot logs for trouble shooting. Yes,
logging has been added but that's not the point. And now if the /binary/
logs become corrupt there is no way to recover them.
It's time for openSUSE to become a leader again instead of doing things
just because Fedora does it.
Just my .02¢
--
Ken Schneider
SuSe since Version 5.2, June 1998
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
And here I thought this was a community distro,
but I see it's more of a
dictatorship. :-)
It is more a DOocracy that a dictatorship.
05:41
On Tue, Apr 30, 2013 at 11:57 PM, Ken Schneider - openSUSE
<suse-list3(a)bout-tyme.net> wrote:
On 04/30/2013 10:33 PM, Cristian Rodríguez pecked at
the keyboard and wrote:
*That* is what I've always objected to binary log formats. They're fragile.
Systemd's implementation is fragile too. Mapping files into memory
gives you zero ordering guarantees and zero capability to maintain
consistency in the event of a system crash. And I mean crash, not even
power outage. Mapping doesn't work for logging. It should be undone.
Maybe it's only the runtime log the one mapped, but still that's
fragile. Because it's always the last log entries the ones I'm
interested in, so there's no point in delaying log flushes, or
pretending the "runtime" log can be less persistent than the "final"
log.
It's quite clear systemd's authors don't get logging at all. Logging
can't be fragile.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
I see, DO it my way or go elsewhere.
My final comments:
openSUSE a.k.a. SuSE used to be one of the most stable distros available. Of
late many apps have been forced on the users that were *clearly* pre-alpha.
I don't remember the releases but the first major fuckup was zypper (or it's
backend) that clearly was forced out before it was ready. The next I recall
was KDE4 that was clearly pre-alpha when made the default install version.
And now systemd has been forced on the masses even though it is not
production ready. And this is the point, many sys admins use openSUSE on
production servers. Why? Because in the past it was *that* stable. Nowadays
not so much. Who in their right mind can risk running a server without boot
logs for trouble shooting. Yes, logging has been added but that's not the
point. And now if the /binary/ logs become corrupt there is no way to
recover them.
It's time for openSUSE to become a leader again instead of doing things just
because Fedora does it. And here I thought this was a community distro,
but I see it's more of a
dictatorship. :-)
It is more a DOocracy that a dictatorship.
05:55
El 01/05/13 00:41, Claudio Freire escribió:
*That* is what I've always objected to binary log
formats. They're fragile.
is mysql/postgresql/sqlite/oracledb fragile ?
Mapping files into memory
gives you zero ordering guarantees and zero capability
to maintain
consistency in the event of a system crash.
Syslog also has a buffer, if you system crashes, that's it, you are done.
Mapping doesn't work for logging. It should be
undone.
Good luck with that, you will have to provide convincing technical
arguments + evidence that is wrong and/or code in the process, otherwise
no one will listen.
It's quite clear systemd's authors
don't get logging at all. Logging
can't be fragile.
It is quite clear that you don't get how the system actually works and
you are mounting an straw-man argument, comparing the journal to an
imaginary logging system that has never existed.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
06:06
El 01/05/13 00:41, Claudio Freire escribió:
And I mean crash, not even
power outage.
The journal TODO list includes :
-import and delete pstore filesystem content at startup
That means, in systems that have the adequate firmware, the journal will
import the "last messages" your system produced before rebooting due to
crash, straight from the dead..spooky :-)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
19:52
On Wed, May 1, 2013 at 2:06 AM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
El 01/05/13 00:41, Claudio Freire escribió:
No, storage systems don't work like that when you're mapping.
Don't think I don't understand how the system works, because I've read
the source. I've written patches for postgres (not upstreamed yet), so
I kinda know a little bit about this stuff. Let me tell you.
When you mmap files, you tell the kernel's page cache to do all I/O
for you. That's fast, because you've got a zero-copy environment like
that. But it's also quite out of your control how writes happen in the
end. When you write to a mapped memory location, you make that page
dirty. The kernel will flush it whenever it thinks it's necessary, in
no particular order.
Pages you dirtied 30 minutes ago can still be unwritten when a page
that has been written 1 second ago is flushed, because somehow the
kernel thinks that old page is hot and so won't flush it unless it's
told to. You tell it to with msync. Systemd just started using msync
for this very reason.
But msync flushes everything. And, again, in no particular order. If
there's a crash, or a power outage, you don't know which pages have
been written and which haven't. Postgres and most reasonably reliable
databases you mention will have a WAL to make sure pages are written
in the right order, and no torn pages appear. The WAL is a file opened
in sync I/O mode. It's slow, but safe. And it's not too slow since
it's append-only, which lets the operating system optimize sync I/O
quite a bit.
In append-only mode, you can have only one torn page: the last one. So
WAL entries are checksummed, and when WAL is replayed, you know
everything up to the first bad checksum is OK. You cannot do that with
memory mapped I/O, you have no way to force a specific write order.
So you're left with a system that will work most of the time, when the
thing crashing isn't the I/O. But if somehow I/O is interrupted (say a
bad interface, a kernel crash, a power outage), the binary format will
be messed with little hope of repair. Torn pages will have old info
interspersed with new info. Not all dirty pages will have been
written, and you have no way to know. If you implemented some kind of
page time-stamping, you'd have to be careful to match page size to
sector size, and assuming you get that right, you'd loose a lot more
info than you would if you hadn't mapped, because you'll have to
discard all valid pages after the first corrupted stamp.
So, memory mapped I/O is wrong if you need reliability. It's great
read-only, but that's about it.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
And I mean crash, not even
power outage.
The journal TODO list includes :
-import and delete pstore filesystem content at startup
That means, in systems that have the adequate firmware, the journal will
import the "last messages" your system produced before rebooting due to
crash, straight from the dead..spooky :-) 
2 May
2 May
05:26
On Wednesday 2013-05-01 20:52, Claudio Freire wrote:
You can have order with mmap. In fact, OpenLDAP developer Howard Chu
presented the inner workings of a new MDB backend last year at
LinuxCon Europe. mdb is all about mmap and uses COW with 2 snapshots
{current,previous} at any time,[1,2] ensuring reliability whilst
keeping speed.
[1] www.openldap.org/pub/hyc/mdm-paper.pdf
[2] www.openldap.org/pub/hyc/mdm-slides.pdf
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That means, in systems that have the adequate firmware, the journal will
import the "last messages" your system produced before rebooting due to
crash, straight from the dead..spooky :-)
Don't think I don't understand how the system works, because I've read
the source. I've written patches for postgres (not upstreamed yet), so
I kinda know a little bit about this stuff. Let me tell you.
When you mmap files,[...] it's also quite out of your control how
writes happen in the end.[...] Pages you dirtied 30 minutes ago can
still be unwritten[...] You tell it [the kernel] to [flush] with
msync. [...] But msync flushes everything. And, again, in no
particular order. If there's a crash, or a power outage, you don't
know which pages have been written and which haven't. Postgres and
most reasonably reliable databases you mention will have a WAL to
make sure pages are written in the right order, and no torn pages
appear. The WAL is a file opened in sync I/O mode. It's slow, but
safe.[...] with memory mapped I/O, you have no way to force a
specific write order. 
06:03
New subject: [opensuse-factory] Re: Re: What is the purpose of the systemd journal service?
On Thu, 2 May 2013 06:26, Jan Engelhardt <jengelh@...> wrote:
Thanks for the links, but keep one thing in mind:
In LDAP there are much more reads than writes.
Syslogs are mostly writes ans little reads.
That, coupled with the need of reliable crash
recovery, makes mmap and consorts much less
suited for the use in logging esp. Syslog.
Personally I deem the binary format of systemd-journal
for one of the biggest dips in the toilet since the
start of Unix, even json would be a big improvement.
Maybe the package systemd-logger should not made available
until the jounal has gotten a complete overhaul.
Looking at the code, there are big ideas, but then
the ball was dropped, fast and deep.
mmap makes sense for readonly (e.g. libs), or read
mostly (e.g. webserver, ldap), with a msync after
a write, but for a log? - Just no.
And the binary format does not help any,
checksums can be added to text formats, and
what sense does the added cryptography make?
Someone has taken hot fecal matter and used a
rotating device to distribute.
Back to the subject:
"What is the purpose of the systemd journal service?"
Answer: Forwarder for external or on-system real syslog service.
- Yamaban, who bemoans the lost ours for looking at the code.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Wednesday 2013-05-01 20:52, Claudio Freire wrote:
[snip]
particular
order. If there's a crash, or a power outage, you don't
know which pages have been written and which haven't. Postgres and
most reasonably reliable databases you mention will have a WAL to
make sure pages are written in the right order, and no torn pages
appear. The WAL is a file opened in sync I/O mode. It's slow, but
safe.[...] with memory mapped I/O, you have no way to force a
specific write order.
You can have order with mmap. In fact, OpenLDAP developer Howard Chu
presented the inner workings of a new MDB backend last year at
LinuxCon Europe. mdb is all about mmap and uses COW with 2 snapshots
{current,previous} at any time,[1,2] ensuring reliability whilst
keeping speed.
[1] www.openldap.org/pub/hyc/mdm-paper.pdf
[2] www.openldap.org/pub/hyc/mdm-slides.pdf
07:15
New subject: [opensuse-factory] Re: Re: What is the purpose of the systemd journal service?
On Thu, May 2, 2013 at 2:03 AM, Yamaban <foerster(a)lisas.de> wrote:
On Thu, 2 May 2013 06:26, Jan Engelhardt
<jengelh@...> wrote:
Thanks for the links, but keep one thing in mind:
In LDAP there are much more reads than writes.
Syslogs are mostly writes ans little reads.
That, coupled with the need of reliable crash
recovery, makes mmap and consorts much less
suited for the use in logging esp. Syslog.
Not only that. msync only flushes to the file system, but there is no
guarantee it will reach the disc. Ie: it flushes dirty pages, but
doesn't execute a write barrier. If you map an O_DIRECT file
descriptor with msync, the performance is abysmal under heavy writes.
Or was last time I tried.
So, LDAP's technique doesn't scale for write-heavy workloads. I will
certainly read the papers though...
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Wednesday 2013-05-01 20:52, Claudio Freire wrote:
[snip]
particular order. If there's a crash, or a power outage, you don't
know which pages have been written and which haven't. Postgres and
most reasonably reliable databases you mention will have a WAL to
make sure pages are written in the right order, and no torn pages
appear. The WAL is a file opened in sync I/O mode. It's slow, but
safe.[...] with memory mapped I/O, you have no way to force a
specific write order.
You can have order with mmap. In fact, OpenLDAP developer Howard Chu
presented the inner workings of a new MDB backend last year at
LinuxCon Europe. mdb is all about mmap and uses COW with 2 snapshots
{current,previous} at any time,[1,2] ensuring reliability whilst
keeping speed.
[1] www.openldap.org/pub/hyc/mdm-paper.pdf
[2] www.openldap.org/pub/hyc/mdm-slides.pdf 
1 May
1 May
18:42
Hello,
Am Dienstag, 30. April 2013 schrieb Ken Schneider - openSUSE:
openSUSE a.k.a. SuSE used to be one of the most stable
distros
available. Of late many apps have been forced on the users that were
*clearly* pre-alpha. I don't remember the releases but the first
major fuckup was zypper (or it's backend) that clearly was forced
out before it was ready.
Now you are bashing the wrong target ;-)
You forgot ZENworks / ZMD which was pushed into SUSE Linux[1] 10.1.
_That_ was pre-alpha, which resulted in 10.1 being the only release with
9 (!) betas and even a "10.1 Remastered" release.
IMHO even /bin/true was more useful than ZMD ;-) which also means zypper
was a big improvement. I agree that the first zypper versions were far
from perfect, but they were much better than ZMD (and therefore an
improvement).
I commiserate with the poor soul that still has to maintain ZMD for the
SLE10 [2] customers...
Regards,
Christian Boltz
[1] yes, 10.1 was still called "SUSE Linux"
[2] assuming it wasn't replaced by zypper with one of the service packs
(I don't know much about SLE)
PS: non-random signature ;-)
--
systemd is the worst thing I have seen in ten years with
SuSE distributions, comparable perhaps only with zmd.
[Michal Kubecek in https://bugzilla.novell.com/725917#c38]
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
19:53
On 05/01/2013 01:42 PM, Christian Boltz pecked at the keyboard and wrote:
Hello,
Am Dienstag, 30. April 2013 schrieb Ken Schneider - openSUSE:
Yes, my memory is not so good lately. :-) I was trying to think of the
bastard CLI update program that was forced into the distro by Novell and
needed numerous updates itself in the first few weeks of release.
openSUSE a.k.a. SuSE used to be one of the most
stable distros
available. Of late many apps have been forced on the users that were
*clearly* pre-alpha. I don't remember the releases but the first
major fuckup was zypper (or it's backend) that clearly was forced
out before it was ready.
Now you are bashing the wrong target ;-)
You forgot ZENworks / ZMD which was pushed into SUSE Linux[1] 10.1.
_That_ was pre-alpha, which resulted in 10.1 being the only release with
9 (!) betas and even a "10.1 Remastered" release.
IMHO even /bin/true was more useful than ZMD ;-) which also means zypper
was a big improvement. I agree that the first zypper versions were far
from perfect, but they were much better than ZMD (and therefore an
improvement).
I agree after having been reminded of ZMD.
I commiserate with the poor soul that still has to maintain ZMD for the
SLE10 [2] customers...
--
Ken Schneider
SuSe since Version 5.2, June 1998
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
14 May
14 May
09:28
On 01/05/13 04:57, Ken Schneider - openSUSE wrote:
fuckup was zypper (or it's backend) that clearly
was forced out before
The screw up was libzypp 1.x + ZENWorks (both _together_).
Please use the names right, otherwise you will create another stupid
myth around the distribution (like: YaST overwrites your config files)
ZENWorks was forced in because of business reasons from the main
stakeholder: at that time that were the only reasons because SUSE was
the only contributor.
--
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
1 May
1 May
08:05
* Cristian Rodríguez <crrodriguez(a)opensuse.org> [2013-05-01 04:33]:
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
Then how about you fix my packages the next time systemd breaks
them? Because right now its a few people who make decisions and
impose a whole lot more unnecessary (since there is no practical
gain) work on others.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
And here I thought this was a community distro,
but I see it's more of a
dictatorship. :-)
It is more a DOocracy that a dictatorship.
08:54
On 05/01/2013 03:05 AM, Guido Berhoerster wrote:
* Cristian Rodríguez <crrodriguez(a)opensuse.org>
[2013-05-01 04:33]:
If you do not want to maintain packages that keep running correctly with
the underlying system changes then you should find another person to
take care of them or file a drop request.
Before "systemd breaks them" (not sure what that means, as the unit
format and documented/expected behaviour has not changed) they will
first break when autotools,compiler, or whatever library they depend
changes.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 30/04/13 22:11, Ken Schneider - openSUSE
escribió:
Then how about you fix my packages the next time systemd breaks
them? And here I thought this was a community distro,
but I see it's more of a
dictatorship. :-)
It is more a DOocracy that a dictatorship.
10:16
Am 01.05.2013 09:54, schrieb Cristian Rodríguez:
If you do not want to maintain packages that keep
running correctly with
the underlying system changes then you should find another person to
take care of them or file a drop request.
Ok, I'll consider that next time.
Before "systemd breaks them" (not sure what
that means, as the unit
format and documented/expected behaviour has not changed)
Oh, for example the whole "systemd's friends now take care of power
management" which was a subtle change in default that obscurely broke
running sytems.
they will
first break when autotools,compiler, or whatever library they depend
changes.
That's easy breakage: compile failures are easy to fix. They don't
silently break a previously running system.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
4 May
4 May
23:40
New subject: [opensuse-factory] reverting broken changes that break stuff, is also "doing the work"
Cristian Rodríguez wrote:
Objecting does not mean anything, those who do the work are the ones
that take decisions.
----
So if I am willing to revert the latest changes to push to systemd, that's
all that is required to have it happen?
Yeah. Right.
Those who do the work are those who are ***allowed*** to do the work.
Second point -- those who do the work are the ones that take decisions -- so
in other words, they don't have to consider anyone else nor be concerned about
who's work they break?
Are you going sit back and let someone do the work of reverting all the damage --
no, you'd complain that they broke your new stuff. Well, in you doing your work,
you are breaking things that used to work for the rest of us.
If those who do the work break things that work for other people -- they can't
just say "not supported". Under those rules, there is no reason why anyone
can't "do the work" of reverting the new, incompatible and alpha-level
features.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
1 May
1 May
09:57
Am 01.05.2013 03:04, schrieb Joachim Schrod:
Lars Marowsky-Bree wrote:
Even though I don't agree with Cristian completely regarding systemd and
journal, I have to defend him here:
* he does care for bug reports.
* he does fix stuff.
My gripes are more with systemd upstream and the mindset there (and of
course it is a good question to blindly follow an upstream, no matter
how stupid it might be, but that is a different question).
About "those who are doing the work decide": the problem is, that now
the ones trying to keep sysvinit alive are actively combatted by the
systemd proponents by removing all the init scripts so that they have to
fork the whole distribution and not just maintain a single package.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On 2013-04-30T11:38:19, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Because the community didn't object when it was merged, or during the
beta phase.
Oh, many of us objected, but were ignored. In fact, look at
Christian's reaction to Stefan's bug report -- no comment needed,
denial at its best.
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
How can such untested alpha quality stuff
make it into a distro? 
2 May
2 May
09:35
On Wed, May 01, 2013 at 10:57:48AM +0200, Stefan Seyfried wrote:
About "those who are doing the work decide":
the problem is, that now
the ones trying to keep sysvinit alive are actively combatted by the
systemd proponents by removing all the init scripts so that they have to
fork the whole distribution and not just maintain a single package.
Well, after spending some time on making 12.3 work again, I must say
that removing the init scripts isn't the real problem. Neither is
dropping whole packages, one can just recover the last (or sufficiently
recent) working version. The real problem are silent changes removing
or breaking functionality not necessary for systemd-only systems, often
undocumented or poorly documented. Finding out which particular change broke
something can be quite a challenge.
But above all, the "do-ocracy" theory is just a big lie. People wanting
working sysvinit didn't have to _do_ anything: it was there and it
worked so there was nothing to _do_ for it, just keep it working. And
even if we wanted to keeping it working, we weren't allowed because
from the very beginning there was a premise that keeping two boot
systems is a waste of effort and that systemd is the only one worth
having. Period, end of discussion, before it even started. Well, there
was a lot of discussion but arguments of people thinking otherwise were
never given serious chance. The people with power to decide were already
determined to get rid of sysvinit, the only question really considered
was how long will it take. And this has nothing to do with "do-ocracy".
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
10:01
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday, 2013-05-02 at 10:35 +0200, Michal Kubecek wrote:
But above all, the "do-ocracy" theory is
just a big lie. People wanting
working sysvinit didn't have to _do_ anything: it was there and it
worked so there was nothing to _do_ for it, just keep it working. And
even if we wanted to keeping it working, we weren't allowed because
from the very beginning there was a premise that keeping two boot
systems is a waste of effort and that systemd is the only one worth
having. Period, end of discussion, before it even started. Well, there
was a lot of discussion but arguments of people thinking otherwise were
never given serious chance. The people with power to decide were already
determined to get rid of sysvinit, the only question really considered
was how long will it take. And this has nothing to do with "do-ocracy".
+1
- --
Cheers,
Carlos E. R.
(from 12.1 x86_64 "Asparagus" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlGCK3MACgkQtTMYHG2NR9VmegCfZaGjQCU9XUWBU7/VyRUQZShg
rPAAn13ftKhZ5+QvNkmG/uYFU1tPZ87B
=KAl4
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
15:55
On Thu, May 2, 2013 at 5:35 AM, Michal Kubecek <mkubecek(a)suse.cz> wrote:
But above all, the "do-ocracy" theory is
just a big lie. People wanting
working sysvinit didn't have to _do_ anything: it was there and it
worked so there was nothing to _do_ for it, just keep it working. And
even if we wanted to keeping it working, we weren't allowed because
from the very beginning there was a premise that keeping two boot
systems is a waste of effort and that systemd is the only one worth
having. Period, end of discussion, before it even started. Well, there
was a lot of discussion but arguments of people thinking otherwise were
never given serious chance. The people with power to decide were already
determined to get rid of sysvinit, the only question really considered
was how long will it take. And this has nothing to do with "do-ocracy".
Well, TBH, keeping the two boot systems in place, interoperable and
easily switchable *was* indeed gonna be a lot of effort.
It's the same as maintaining multi-distro packages. I've done a couple
of those, and the subtle differences between the distros makes it
really difficult, especially deb-based ones which have none of RPM's
magic. With sysvinit vs systemd was the same. There was no magic in
place to make it easier, and packages that had to interact with either
would and had become a lot harder to maintain just because they had to
handle two very different init systems.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
4 May
4 May
15:03
Stefan Seyfried wrote:
Am 01.05.2013 03:04, schrieb Joachim Schrod:
----
That hasn't been my experience.
Any bug or problem I've submitted and he'd commented on he's
told me is my problem and it's no longer supported.
His attitude sucks for someone who is working inside Suse.
The whole attitude of developers like him is that distro's are there
to support *them* -- and customers are on their own.
Oh, many of us objected, but were ignored. In
fact, look at
Christian's reaction to Stefan's bug report -- no comment needed,
denial at its best.
Even though I don't agree with Cristian completely regarding systemd and
journal, I have to defend him here:
* he does care for bug reports.
* he does fix stuff.
About "those who are doing the work decide": the problem is, that now
the ones trying to keep sysvinit alive are actively combatted by the
systemd proponents by removing all the init scripts so that they have to
fork the whole distribution and not just maintain a single package.
----
Yup.... had to replace all of them -- went back to 11.3 sources on
several -- including sysVinit. The deliberate laying of traps and working
to destroy compatibility are acts of deliberate malice.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
15:15
New subject: [opensuse-factory] Re: What is the purpose of the systemd journal service?
On Sat, May 04, 2013 at 07:03:01AM -0700, Linda Walsh wrote:
Stefan Seyfried wrote:
Cristian is a community member, not a SUSE employee. Just to get this straight.
Am 01.05.2013 03:04, schrieb Joachim Schrod:
----
That hasn't been my experience.
Any bug or problem I've submitted and he'd commented on he's
told me is my problem and it's no longer supported.
His attitude sucks for someone who is working inside Suse. Oh, many of us objected, but were ignored. In
fact, look at
Christian's reaction to Stefan's bug report -- no comment needed,
denial at its best.
Even though I don't agree with Cristian completely regarding systemd and
journal, I have to defend him here:
* he does care for bug reports.
* he does fix stuff. The whole attitude of developers like him is that
distro's are there
to support *them* -- and customers are on their own.
Well, see above.
Ciao, Marcus
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
1 May
1 May
20:09
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday, 2013-04-30 at 12:21 +0200, Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier <>
wrote:
Because the community didn't object when it was merged, or during the
beta phase.
What? :-O
Community objections are routinely ignored. There is no point in objecting :-/
- --
Cheers,
Carlos E. R.
(from 12.1 x86_64 "Asparagus" at Telcontar)
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
How can such untested alpha quality stuff
make it into a distro? -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlGBaFgACgkQtTMYHG2NR9WnzwCbBcEJ4HpJY57o185YwAA400fF
7fQAnAhhMw15kZKcQEwjr4VE4zdla/48
=Rdq2
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
2 May
2 May
09:44
Carlos E. R. wrote:
On Tuesday, 2013-04-30 at 12:21 +0200, Lars
Marowsky-Bree wrote:
+1
--
Per Jessen, Zürich (14.6°C)
http://www.dns24.ch/ - free DNS hosting, made in Switzerland.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On 2013-04-30T11:38:19, Ruediger Meier <>
wrote:
Because the community didn't object when it was merged, or during the
beta phase.
What? :-O
Community objections are routinely ignored. There is no point in
objecting :-/
That's why it is called --verify and not --repair .. (not
implemented yet, never advertised as repair either)
How can such untested alpha
quality stuff make it into a distro?
4 May
4 May
14:50
Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
Because the community didn't object when it was merged, or during the
beta phase.
====
Many members of the community objected and were put in the developer's kill
lists.
Objecting is the quickest way to get ignored and be told that anything bad
that happens on your system is your own fault for touching your system.
If people would stop touching their systems and expecting to use them for
their own purposes, they wouldn't have any problems with the way they
no longer function. ;-|
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
How can such untested alpha quality stuff
make it into a distro?
30 Apr
30 Apr
11:24
New subject: [opensuse-factory] Re: Re: What is the purpose of the systemd journal service?
On Tue, 30 Apr 2013 11:38, Ruediger Meier <sweet_f_a@...> wrote:
How can such untested alpha quality stuff make it into a distro?
Done daily by really big companies: Microsoft, Oracle, ... ,
the smaller companies take that as example.
And: OSS and Fedora ARE the playgrounds for the Pro-versions: SLE + RHEL
Yes that hurts, but OTOH there's a big cry for the latest features,
examples that I'll give you:
- Btrfs - without fs-repair tools for a long time, nice, ne?
- systemd in OSS 12.1 + 12.2 was half done at best, 12.3 80-90% done
- pulse-audio (did it work anywhere without troubles, yet?)
No, as diving the cry for the latest-greatest is, it also hinders in
debugging the existing problems, as a day has only 24 hours, for everybody.
We made our bed, now we have to lay in it.
Back to the Subject:
+1 for strong recommend of extra syslog service (syslog-ng / rsyslog).
+1 no no recommend, and/or suggest of "systemd-logger" in any package
+1 for an added warning in "systemd-logger" Description:
"Not ready for use, testing only, logs may disappear with no warning."
- Yamaban.
PS: @Ruediger: did you test? If no, you did not help to find the bugs.
Stefan did so, but did not have enough warning to keep another
logging service running. And yes, the docu is ambiguous and unclear.
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
> On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
[snip]
* if the database is broken, i tells you (journalctl
--verify)
* but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
12:00
New subject: [opensuse-factory] Re: Re: What is the purpose of the systemd journal service?
Am 30.04.2013 12:24, schrieb Yamaban:
PS: @Ruediger: did you test? If no, you did not help
to find the bugs.
Stefan did so, but did not have enough warning to keep another
logging service running. And yes, the docu is ambiguous and unclear.
Actually I have, but unfortunately syslog-ng is also buggy since some
weeks and stops logging after some period of time :-(
https://bugzilla.novell.com/815746
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
13:24
New subject: [opensuse-factory] Re: Re: What is the purpose of the systemd journal service?
On 04/30/2013 01:00 PM, Stefan Seyfried wrote:
Am 30.04.2013 12:24, schrieb Yamaban:
The strange thing is, that we could not
reproduce it in house. I was
running 3.4 on my machines for weeks without problems before committing
it to Factory. One of the core syslog-ng developers is checking the
problem in a VM, and I'm also running syslog-ng on my openSUSE desktop
all the time and never ran into this problem. We need to be able to
reproduce it to fix it...
Bye,
CzP
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
PS: @Ruediger: did you test? If no, you did not
help to find the bugs.
Stefan did so, but did not have enough warning to keep another
logging service running. And yes, the docu is ambiguous and unclear.
Actually I
have, but unfortunately syslog-ng is also buggy since some
weeks and stops logging after some period of time :-(
https://bugzilla.novell.com/815746
1 May
1 May
04:06
New subject: [opensuse-factory] Re: Re: What is the purpose of the systemd journal service?
El 30/04/13 08:24, Peter Czanik escribió:
The strange thing is, that we could not reproduce it
in house.
I also tried to reproduce the problem with no luck, maybe there is
something very specific to Stefan's environment/hardware that could
possible trigger this issue ? it could also be a bug in glib..
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
10:26
New subject: [opensuse-factory] Re: Re: What is the purpose of the systemd journal service?
Am 01.05.2013 05:06, schrieb Cristian Rodríguez:
El 30/04/13 08:24, Peter Czanik escribió:
I'm trying to find out :-)
It looks like some subtle race condition which are hard to find /
reproduce. I hope the helgrind traces in
https://bugzilla.novell.com/815746 might be helpful.
If anyone has ideas on how to debug this or for more helpful helgrind
options -- I'm all for it.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
The strange thing is, that we could not reproduce
it in house.
I also tried to reproduce the problem with no luck, maybe there is
something very specific to Stefan's environment/hardware that could
possible trigger this issue ? it could also be a bug in glib..
4 May
4 May
15:22
Stefan Seyfried wrote:
Am 30.04.2013 12:24, schrieb Yamaban:
not version 2.0.9.
I put it in place and made it immutable. It never crashes.
Yeah.. its old, but it works.
Seems to be a good idea to keep around a backup 'root' or two
and copy in the working binaries after installing recent updates...
One finds that recent updates install dummy scripts for working binaries.
Good to have working binaries.
For those that think systemd = linux, it's not. systemd=windows -- it's a
corporate
shove down your throat. Gnu-linux has been about there being more than one way
to do things. That's an *open* system. Closed ones are where choice is
dictated and
removed.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
PS: @Ruediger: did you test? If no, you did not
help to find the bugs.
Stefan did so, but did not have enough warning to keep another
logging service running. And yes, the docu is ambiguous and unclear.
Actually I have, but unfortunately syslog-ng is also buggy since some
weeks and stops logging after some period of time :-(
https://bugzilla.novell.com/815746
30 Apr
30 Apr
13:01
New subject: [opensuse-factory] Re: Re: What is the purpose of the systemd journal service?
On Tuesday 30 April 2013, Yamaban wrote:
On Tue, 30 Apr 2013 11:38, Ruediger Meier
<sweet_f_a@...> wrote:
How can such untested alpha quality stuff make it into a distro?
Done daily by really big companies: Microsoft, Oracle, ... ,
the smaller companies take that as example.
And: OSS and Fedora ARE the playgrounds for the Pro-versions: SLE +
RHEL
Yes that hurts, but OTOH there's a big cry for the latest features,
examples that I'll give you:
- Btrfs - without fs-repair tools for a long time, nice, ne?
- systemd in OSS 12.1 + 12.2 was half done at best, 12.3 80-90% done
- pulse-audio (did it work anywhere without troubles, yet?)
On Tuesday 30 April 2013, Cristian Rodríguez
wrote:
> On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
[snip]
* if the database is broken, i tells you (journalctl
--verify)
* but it can not repair or recover it
That's why it is called --verify and not --repair .. (not
implemented yet, never advertised as repair either) No, as diving the cry for the latest-greatest is, it
also hinders in
debugging the existing problems, as a day has only 24 hours, for
everybody.
We made our bed, now we have to lay in it.
Back to the Subject:
+1 for strong recommend of extra syslog service (syslog-ng /
rsyslog). +1 no no recommend, and/or suggest of "systemd-logger" in
any package +1 for an added warning in "systemd-logger" Description:
"Not ready for use, testing only, logs may disappear with no
warning."
- Yamaban.
PS: @Ruediger: did you test? If no, you did not help to find the
bugs. Stefan did so, but did not have enough warning to keep another
logging service running. And yes, the docu is ambiguous and unclear.
No, I'm a user and don't want to see or fix alpha bugs, specially if
they affect things which worked without any problem since always ...
I had run some quick tests of openSUSE 12.1, 12.2, 12.3 which where
enough for me to see that they are unusable. I still run 11.4 on all
production machines. One of my experimental machines (desktop at home)
is 12.2 with sysvinit.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
11:38
I would second the general complaint about software quality, having
just 'upgraded' to 12.3, the latest KDE is also a mess especially KMail
2 which is another alpha quality disaster!
There is a patten emerging here, especially in German based projects,
of Grand Ideas, that do nothing to meet user need, break existing
functionality, and are stoutly defended by evangelists and UI
designers.
It may look pretty, but just under the skin it is barely alpha quality
crap!
Cheers, omb
Am Tue, 30 Apr 2013 11:38:19 +0200, scheib Ruediger
Meier:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
How can such untested alpha quality stuff make it into a distro?
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org I give a sh*t on that design document, as long as
I can not read my
logs, it is the end of the month and they would be very useful to
do my accounting.
Fun facts about sytemd-journal:
* it logs to a binary database
Yes.
* it can not filter out the user session logs
from the system logs
Something can be done about that..I thought it was able to so
* if the database is broken, i tells you
(journalctl --verify)
* but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
12:18
New subject: [opensuse-factory] Re: What is the purpose of the systemd journal service?
On Tue, Apr 30, 2013 at 11:38:19AM +0200, Ruediger Meier wrote:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
Fun thing is of course as the "corrupted" journal is cryptographically
ensured, it is better not to look at if it is corrupted ;)
Ciao, Marcus
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
How can such untested alpha quality stuff make it into a distro? I give a sh*t on that design document, as long as
I can not read my
logs, it is the end of the month and they would be very useful to
do my accounting.
Fun facts about sytemd-journal:
* it logs to a binary database
Yes.
* it can not filter out the user session logs
from the system logs
Something can be done about that..I thought it was able to so
* if the database is broken, i tells you
(journalctl --verify)
* but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented
yet, never advertised as repair either)
12:20
Am 30.04.2013 13:18, schrieb Marcus Meissner:
Fun thing is of course as the "corrupted"
journal is cryptographically
ensured, it is better not to look at if it is corrupted ;)
My journal files here are not technically corrupt (I removed the ones
that failed --verify), but it still can not be read as it puts
journalctl in an endless loop.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
17:33
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into
a distro?
is btrfs alpha too ? it also does not have fsck.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
17:36
On Tuesday 2013-04-30 18:33, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
btrfs scrub
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
18:14
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
Don't know. Last time I've tested it wasn't stable and IMO it still
shouldn't be the default.
But anyway at least users have the choice to use any other FS.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
1 May
1 May
02:49
El 30/04/13 13:14, Ruediger Meier escribió:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
in this world, nothing will be ever stable and production ready if it is
not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 30/04/13 05:38, Ruediger Meier escribió:
Don't know. Last time I've tested it wasn't stable and IMO it still
shouldn't be the default. How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
03:23
On 04/30/2013 09:49 PM, Cristian Rodríguez pecked at the keyboard and wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
And depending on the dev doing the work it will _never_ be stable. Or
they have their head so far up there #$% that they can't be objective
about the app they are developing.
--
Ken Schneider
SuSe since Version 5.2, June 1998
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Tuesday 30 April 2013, Cristian Rodríguez
wrote:
in this world, nothing will be ever stable and production ready if it is
not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air.
El 30/04/13 05:38, Ruediger Meier escribió:
Don't know. Last time I've tested it wasn't stable and IMO it still
shouldn't be the default. How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
13:21
On Wednesday 01 May 2013, Cristian Rodríguez wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
You miss the point that btrfs seems to be pre-stable while systemd is
obviously still alpha and it's integration into openSUSE is pre-aplha.
These alpha problems could be surely found and solved before giving it
to the masses. But it would need to have some developers and packagers
with sense for the interesting use cases in practice (beyond single
user laptop) rather than only people who just "want to do the work".
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Tuesday 30 April 2013, Cristian Rodríguez
wrote:
in this world, nothing will be ever stable and production ready if it
is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air. El 30/04/13 05:38, Ruediger Meier escribió:
Don't know. Last time I've tested it wasn't stable and IMO it still
shouldn't be the default. How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
16:17
On Wed, 1 May 2013 14:21:21 +0200
Ruediger Meier <sweet_f_a(a)gmx.de> wrote:
...
But it would need to have some developers and
packagers with sense
for the interesting use cases in practice (beyond single user laptop)
Better to say developer's laptop, as taking over power management
showed that they are really self centric. They wanted to drop all the
quirks collected trough time that allowed users to run Linux on
hardware (HW) with buggy BIOS.
While in theory bug in BIOS is a problem that hardware provider should
solve, in practice, that BIOS works fine in Windows and its vendor will
do nothing to fix a problem. User that installs Linux and have a
problem will just ditch new toy.
rather than only people who just "want to do the
work".
I guess that early adopters, testers and bug reporters are also those
that do the work, provided time to catch up with changes. If one pushes
more that they can swallow whole idea of testing software falls apart.
It is as simple as a streetcar (tram).
If it stops all passengers will enter.
If it slows down, those that can run and jump can enter.
If it doesn't slow down only few athletes will be able to catch a
moment and enter.
In other words, adjust your speed to ability of "passengers" you want,
or you will have no income very soon.
As it is now:
* systemd and relatives are requiring days of full time engagement to
learn, which excludes all that can't take that much time. Learning at
the slow pace is Sisyphus task, as by the time you learn something,
there is more to learn and some to forget.
* changes are at the level that backport to older openSUSE releases is
not viable, which excludes from testing all that have reasons not to
use the latest release. One of reasons is, probably, lack of time to
port application settings and data every 8 months.
--
Regards, Rajko.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
17:27
El 01/05/13 11:17, Rajko escribió:
They wanted to drop all the
quirks collected trough time that allowed users to run
Linux on
hardware (HW) with buggy BIOS.
Well, yeah . because guess what .. workarounds or fixes for buggy BIOS
do not belong in userspace, they have to be fixed in the kernel.
You are preaching to the wrong choir.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
2 May
2 May
00:30
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday, 2013-05-01 at 10:17 -0500, Rajko wrote:
Absolutely!
On Wed, 1 May 2013 14:21:21 +0200 Ruediger Meier
<> wrote:
...
Indeed.
But it would need to have some developers and
packagers with sense
for the interesting use cases in practice (beyond single user laptop)
Better to say developer's laptop, as taking over power management
showed that they are really self centric. They wanted to drop all the
quirks collected trough time that allowed users to run Linux on
hardware (HW) with buggy BIOS.
While in theory bug in BIOS is a problem that hardware provider should
solve, in practice, that BIOS works fine in Windows and its vendor will
do nothing to fix a problem. User that installs Linux and have a
problem will just ditch new toy. rather than
only people who just "want to do the work".
I guess that early adopters, testers and bug reporters are also those
that do the work, provided time to catch up with changes. If one pushes
more that they can swallow whole idea of testing software falls apart. In other words, adjust your speed to ability of
"passengers" you want,
or you will have no income very soon.
Right.
As it is now:
* systemd and relatives are requiring days of full time engagement to
learn, which excludes all that can't take that much time. Learning at
the slow pace is Sisyphus task, as by the time you learn something,
there is more to learn and some to forget.
Yep.
* changes are at the level that backport to older
openSUSE releases is
not viable, which excludes from testing all that have reasons not to
use the latest release. One of reasons is, probably, lack of time to
port application settings and data every 8 months.
Absolutely.
- --
Cheers,
Carlos E. R.
(from 12.1 x86_64 "Asparagus" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlGBpcAACgkQtTMYHG2NR9WN+QCfUpn2gfH+5LQJeJ/pu0ugAjoR
puEAnj4KR2fRJZhLYC1Qo572XiDcCBR9
=xnQJ
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
4 May
4 May
12:07
From: Ruediger Meier <sweet_f_a(a)gmx.de>
To: opensuse-factory(a)opensuse.org
Subject: Re: [opensuse-factory] Re: What is the purpose of the systemd
journal service?
Date: Wed, 1 May 2013 14:21:21 +0200
On Wednesday 01 May 2013, Cristian Rodríguez wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
You miss the point that btrfs seems to be pre-stable while systemd is
obviously still alpha and it's integration into openSUSE is pre-aplha.
These alpha problems could be surely found and solved before giving it
to the masses. But it would need to have some developers and packagers
with sense for the interesting use cases in practice (beyond single
user laptop) rather than only people who just "want to do the work".
-----Original Message-----
No, still missing points:
Btrfs is still an option, one of the many fs available.
systemd if forced upon on us, not having an alternative.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Tuesday 30 April 2013, Cristian Rodríguez
wrote:
in this world, nothing will be ever stable and production ready if it
is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air. El 30/04/13 05:38, Ruediger Meier escribió:
Don't know. Last time I've tested it wasn't stable and IMO it still
shouldn't be the default. How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
20:26
On Sat, May 4, 2013 at 8:07 AM, Hans Witvliet <suse(a)a-domani.nl> wrote:
On Wednesday 01 May 2013, Cristian Rodríguez wrote:
And all of you seem to miss a much more important point.
Filesystems are interchangeable, at least if I'm building a new system
(and noone's gonna upgrade to btrfs, manually or automatically, since
btrfs is new, and upgrades don't reformat your partitions).
Btrfs is optional, and lots of alternatives are present and usable
inside the distribution. Journal is not. One can opt-out of btrfs. One
can opt-in, in fact. Not so with journal. It's like trying to opt out
of the kernel. Difference (big difference) is, the kernel works.
Journal doesn't.
Sure, journal might work some day. But since it's not something that I
can opt-in or out, it's that day the day when it should've been
introduced into the distro, not today. Now maintainers and everybody
is hard-pressed to fix the bugs, or leave for greener lizardless
pastures.
Thankfully, I didn't have issues with Journal yet. But, I know better
than to deploy any systemd-based openSuse on a server.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 30/04/13 13:14, Ruediger Meier escribió:
You miss the point that btrfs seems to be pre-stable while systemd is
obviously still alpha and it's integration into openSUSE is pre-aplha. On Tuesday 30 April 2013, Cristian Rodríguez
wrote:
in this world, nothing will be ever stable and production ready if it
is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air. El 30/04/13 05:38, Ruediger Meier escribió:
> How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Don't know. Last time I've tested it wasn't stable and IMO it still
shouldn't be the default.
1 May
1 May
20:26
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday, 2013-04-30 at 21:49 -0400, Cristian Rodríguez wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
Not completely true :-)
There are businesses that certify complete reliability and fault free
software. They charge an insane packet for it.
Supposedly free opensource software is better because there is a whole
community of developers verifying the code. >:-P
- --
Cheers,
Carlos E. R.
(from 12.1 x86_64 "Asparagus" at Telcontar)
On Tuesday 30 April 2013, Cristian Rodríguez
wrote:
in this world, nothing will be ever stable and production ready if it is not
widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air. El 30/04/13 05:38, Ruediger Meier escribió:
Don't know. Last time I've tested it wasn't stable and IMO it still
shouldn't be the default. How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlGBbF4ACgkQtTMYHG2NR9VH4wCaA8xPpJYZ/uFX/1ue51idAIm2
/+EAn0THqBpB1w6nBwa10A4jugCdgZ+f
=lJHe
-----END PGP SIGNATURE-----
30 Apr
30 Apr
20:24
Am 30.04.2013 18:33, schrieb Cristian Rodríguez:
El 30/04/13 05:38, Ruediger Meier escribió:
Yes, it is alpha.
And it is a totally different thing as you can opt-out of btrfs.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
20:44
El 30/04/13 15:24, Stefan Seyfried escribió:
Am 30.04.2013 18:33, schrieb Cristian Rodríguez:
If you do not want to use the journal, install a syslog implementation
and set Storage=volatile (or "none", if you know what your doing and
fully accept that systemctl will not output anything about the service
logs, just its status)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 30/04/13 05:38, Ruediger Meier escribió:
Yes, it is alpha.
And it is a totally different thing as you can opt-out of btrfs.
How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
1 May
1 May
09:47
Am 30.04.2013 21:44, schrieb Cristian Rodríguez:
El 30/04/13 15:24, Stefan Seyfried escribió:
Then I still have not opted-out of journald and systemd, which was
Rudi's subject. :-)
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Am 30.04.2013 18:33, schrieb Cristian Rodríguez:
If you do not want to use the journal, install a syslog implementation
and set Storage=volatile (or "none", if you know what your doing and
fully accept that systemctl will not output anything about the service
logs, just its status) El 30/04/13 05:38, Ruediger Meier escribió:
Yes, it is alpha.
And it is a totally different thing as you can opt-out of btrfs.
How can such untested alpha quality stuff make it
into a distro?
is btrfs alpha too ? it also does not have fsck.
20:31
El 01/05/13 04:47, Stefan Seyfried escribió:
Then I still have not opted-out of journald and
systemd, which was
Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required
components in the same sense the kernel is required or a shell is required.
I instructed you how to disable the journal storage. I think that is enough.
If you do not want those components, take a look at few distributions
that do not currently use systemd ,the list gets shorter and shorter
everyday, because systemd has become the de-facto init system by
now.currently the exceptions are debian and slackware (but they wont be
for much long I think)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
20:50
On Wed, May 1, 2013 at 4:31 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
El 01/05/13 04:47, Stefan Seyfried escribió:
I wonder if it would be possible or desirable to write storage
plug-ins (or modules) for journal. I imagine one based on a sane DB
engine might be useful.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Then I still have not opted-out of journald and
systemd, which was
Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required components
in the same sense the kernel is required or a shell is required.
I instructed you how to disable the journal storage. I think that is enough.
If you do not want those components, take a look at few distributions that
do not currently use systemd ,the list gets shorter and shorter everyday,
because systemd has become the de-facto init system by now.currently the
exceptions are debian and slackware (but they wont be for much long I think)
21:00
El 01/05/13 15:50, Claudio Freire escribió:
I wonder if it would be possible or desirable to write
storage
plug-ins (or modules) for journal. I imagine one based on a sane DB
engine might be useful.
There is no API for storage plugins, if you need the journal data to be
stored somewhere else you will be able to consume it via a webservice
that will be provided by systemd-journal-gatewayd or simply by using a
syslog implementation that provides the storage backends.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
21:14
On Wed, May 1, 2013 at 5:00 PM, Cristian Rodríguez
<crrodriguez(a)opensuse.org> wrote:
El 01/05/13 15:50, Claudio Freire escribió:
But that wouldn't apply to journalctl
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
I wonder if it would be possible or desirable to
write storage
plug-ins (or modules) for journal. I imagine one based on a sane DB
engine might be useful.
There is no API for storage plugins, if you need the journal data to be
stored somewhere else you will be able to consume it via a webservice that
will be provided by systemd-journal-gatewayd or simply by using a syslog
implementation that provides the storage backends.
2 May
2 May
00:02
On Wednesday 01 May 2013, Cristian Rodríguez wrote:
El 01/05/13 04:47, Stefan Seyfried escribió:
At least they seem to wait until systemd gets stable but this will not
happen soon I think.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Then I still have not opted-out of journald and
systemd, which was
Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required
components in the same sense the kernel is required or a shell is
required.
I instructed you how to disable the journal storage. I think that is
enough.
If you do not want those components, take a look at few distributions
that do not currently use systemd ,the list gets shorter and shorter
everyday, because systemd has become the de-facto init system by
now.currently the exceptions are debian and slackware (but they wont
be for much long I think)
13 May
13 May
14:33
Le mercredi 01 mai 2013 à 15:31 -0400, Cristian Rodríguez a écrit :
El 01/05/13 04:47, Stefan Seyfried escribió:
Even better, starting with 12.3, we didn't enforce journal storage on
disk by default, since it is now pulled by the "systemd-logger" package
(to allow people to not install any syslog implementation) which is NOT
installed by default.
In 12.2, /var/log/journal was created by default (enabling on disk
journal persistence) and it is kept when upgrading (because we can't
detect if user want to keep it or not). If you don't want it, just
remove the directory.
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Then I still have not opted-out of journald and
systemd, which was
Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required
components in the same sense the kernel is required or a shell is required.
I instructed you how to disable the journal storage. I think that is enough. 
14 May
14 May
06:50
Frederic Crozat <fcrozat(a)suse.com> writes:
Even better, starting with 12.3, we didn't
enforce journal storage on
disk by default, since it is now pulled by the "systemd-logger" package
(to allow people to not install any syslog implementation) which is NOT
installed by default.
In 12.2, /var/log/journal was created by default (enabling on disk
journal persistence) and it is kept when upgrading (because we can't
detect if user want to keep it or not). If you don't want it, just
remove the directory.
Those things would have deserved proper documentation (since you do not
point to documentation, I assume that it does not exist). At least, a
release notes entry is required.
I just created https://bugzilla.novell.com/show_bug.cgi?id=819707 --feel
free to work on it :)
--
Karl Eichwalder SUSE LINUX Products GmbH
R&D / Documentation Maxfeldstraße 5
90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
08:53
Le mardi 14 mai 2013 à 07:50 +0200, Karl Eichwalder a écrit :
Frederic Crozat <fcrozat(a)suse.com> writes:
Indeed, I'll try to draft some text there, feel free to improve it :)
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Even better, starting with 12.3, we didn't
enforce journal storage on
disk by default, since it is now pulled by the "systemd-logger" package
(to allow people to not install any syslog implementation) which is NOT
installed by default.
In 12.2, /var/log/journal was created by default (enabling on disk
journal persistence) and it is kept when upgrading (because we can't
detect if user want to keep it or not). If you don't want it, just
remove the directory.
Those things would have deserved proper documentation (since you do not
point to documentation, I assume that it does not exist). At least, a
release notes entry is required.
I just created https://bugzilla.novell.com/show_bug.cgi?id=819707 --feel
free to work on it :)
09:41
Frederic Crozat wrote:
Le mercredi 01 mai 2013 à 15:31 -0400, Cristian
Rodríguez a écrit :
I did notice this on my test-installs, thanks.
--
Per Jessen, Zürich (14.0°C)
http://www.dns24.ch/ - free DNS hosting, made in Switzerland.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
El 01/05/13 04:47, Stefan Seyfried escribió:
Even better, starting with 12.3, we didn't enforce journal storage on
disk by default, since it is now pulled by the "systemd-logger"
package (to allow people to not install any syslog implementation)
which is NOT installed by default. Then I still have not opted-out of journald and
systemd, which was
Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required
components in the same sense the kernel is required or a shell is
required.
I instructed you how to disable the journal storage. I think that is
enough.
19 Sep
19 Sep
16:59
On Wednesday 19 September 2012, Claudio Freire wrote:
grep is just one particular tool to read text files in a very special
way.
Compiling journalctl on arbitrary systems will be great fun I guess.
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier
<sweet_f_a(a)gmx.de>
wrote:
Unfortunately
you can do this only on machines where journalctl is
installed/available. I assume that you can't read the journald logs
on most existing systems.
Just a matter of building journalctl from source I'd imagine, as
would be the case if you were missing grep. I happen to agree that the binary format is
unnecessary, but it also
happens to be a discretionary power of the author, and as soon as
there's a working and ubiquitous "journalctl" to parse it... and its
accompanying documentations... complaining will only start flame
wars.
Still don't understand why this binary format should be used on
production systems before these "ubiquitous" tools are existing.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
17:06
El 19/09/12 12:59, Ruediger Meier escribió:
Still don't understand why this binary format
should be used on
production systems before these "ubiquitous" tools are existing.
No one has said it should be used, you still have syslog. however
systemd requires the journal. it logs all its operations there.
you can simple remove /var/log/journal if you do not want persistent
storage..systemd will still use the journal for runtime logging or
internal operations in its own private /run/systemd/journal directory...
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
17:06
On Wed, Sep 19, 2012 at 12:59 PM, Ruediger Meier <sweet_f_a(a)gmx.de> wrote:
I don't imagine journalctl's log parsing part to be anything other
than fully portable. It's just a format parser.
Of course, there's lots of ways portability can go out the window. But
those can be fixed as the need arises.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Just a matter
of building journalctl from source I'd imagine, as
would be the case if you were missing grep.
grep is just one particular tool to read text files in a very special
way.
Compiling journalctl on arbitrary systems will be great fun I guess.
12:59
On 09/19/2012 11:53 AM, Per Jessen wrote:
Ditto - also much easier to configure than
rsyslog.
As syslog-ng upstream, I can't agree more :-)
Journal: we consider it as a logging solution for stand alone desktops.
You can read about it in a bit more details at
http://czanik.blogs.balabit.com/2012/03/state-of-the-art-logging-syslog-ng-…
And a bit of self promotion: if you are interested in logging and/or
syslog-ng, be sure to come to the openSUSE conference in Prague, where
I'll give a presentation Sunday, early in the afternoon:
http://conference.opensuse.org/
Bye,
Peter Czanik (CzP)
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Currently it is not a full replacement for syslog but
I suggest you
to check it out.
I tend to use ngsyslog for the filtering benefits. -- really has some
powerful filtering in the 2.x line
16:44
El 19/09/12 06:29, Linda Walsh escribió:
I assume the full power of linux's text
utilities can be
used on them - like grep, sort, awk, perl... vim...
As long as you export them in either text, json, xml...
If I can't look at the whole stream as a text
(messages, warnings, etc),
I don't get a field for what is right or wrong behavior and certainly
wouldn't be able to pick out an anomaly if I had to query each item
separately --
that global view is a good way to look for 'warts'...
you can query items separately or view the whole log...
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
2901
days inactive
3138
days old
129 comments
27 participants
participants (27)
-
Andreas Jaeger -
Carlos E. R. -
Christian Boltz -
Claudio Freire -
Cristian Rodríguez -
Dominique Leuenberger a.k.a DimStar -
Duncan Mac-Vicar P. -
Frederic Crozat -
Guido Berhoerster -
Hans Witvliet -
Jan Engelhardt -
Joachim Schrod -
Karl Eichwalder -
Ken Schneider - openSUSE -
Lars Marowsky-Bree -
Linda Walsh -
Marcus Meissner -
Michal Kubecek -
Nelson Marques -
Per Jessen -
Peter Czanik -
Rajko -
root -
Ruediger Meier -
Stefan Seyfried -
Stephan Kulow -
Yamaban