Re: End of hypocrisy ?
On Mon, 11 Aug 2014 22:15:02 +1000 Zenaan Harkness wrote: > > Don't confuse GNU and GNOME. HINT: What does GIMP stand for? > > GNOME Image Manipulation Package? Oh come on man! Stop with the silly FUD... It doesn't become anyone here... The GIMP has been around a long long time. GIMP: https://en.wikipedia.org/wiki/GIMP GIMP /ɡɪmp/[4] (GNU Image Manipulation Program) is a raster graphics editor. ... Initial release January 1996; 18 years ago ... Written in C, GTK+ ... GIMP was originally released as the General Image Manipulation Program,[6] by creators Spencer Kimball and Peter Mattis. GNOME: https://en.wikipedia.org/wiki/GNOME Initial release March 3, 1999 --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811083028.d3c04c045a5b14e450577...@1024bits.com
Re: End of hypocrisy ?
Zenaan Harkness writes: > GNOME Image Manipulation Package? GNU Image Manipulation Program. It a bit funny but not strange that The Gimp is developed under the banner of the GNOME project: GNOME was created AFTER The Gimp was re-written using GTK (GIMP Tool Kit), providing the uniform look required to create a desktop environment. We have Gnome (thumb down) because we had The Gimp first. -- /\ ___Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_ African word //--\| | \| | Integralista GNUslamicomeaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso...Debian" Warning: gnome-config-daemon considered more dangerous than GOTO -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21480.46633.362720.886...@mail.eng.it
Re: End of hypocrisy ?
On 8/11/14, Chris Bannister wrote: > On Sun, Aug 10, 2014 at 01:23:49PM -0400, Steve Litt wrote: >> On Sun, 10 Aug 2014 06:35:54 -0400 >> Tom H wrote: >> >> >> > Olav Vitters, a Gnome guy who always argues on behalf of Gnome/systemd >> > on debian-devel@ (I don't think that he's involved in Debian in any >> > other way), has said on his blog "it seems eventually GNOME will head >> > to be systemd and Linux-only" >> >> Wow, in which case Gnumeric and Gimp won't work on *BSD, and my friends >> with Windows or Mac won't be able to use them either. > > Don't confuse GNU and GNOME. HINT: What does GIMP stand for? GNOME Image Manipulation Package? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOsGNSSXvXOGeSJ=sa18msoqfrpoimksqydviqmshwugwgl...@mail.gmail.com
Re: End of hypocrisy ?
On Sun, Aug 10, 2014 at 01:23:49PM -0400, Steve Litt wrote: > On Sun, 10 Aug 2014 06:35:54 -0400 > Tom H wrote: > > > > Olav Vitters, a Gnome guy who always argues on behalf of Gnome/systemd > > on debian-devel@ (I don't think that he's involved in Debian in any > > other way), has said on his blog "it seems eventually GNOME will head > > to be systemd and Linux-only" > > Wow, in which case Gnumeric and Gimp won't work on *BSD, and my friends > with Windows or Mac won't be able to use them either. Don't confuse GNU and GNOME. HINT: What does GIMP stand for? -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014083643.GN1063@tal
Re: End of hypocrisy ?
Le 10/08/2014 19:23, Steve Litt a écrit : > On Sun, 10 Aug 2014 06:35:54 -0400 > Tom H wrote: > > >> Olav Vitters, a Gnome guy who always argues on behalf of Gnome/systemd >> on debian-devel@ (I don't think that he's involved in Debian in any >> other way), has said on his blog "it seems eventually GNOME will head >> to be systemd and Linux-only" > Wow, in which case Gnumeric and Gimp won't work on *BSD, and my friends > with Windows or Mac won't be able to use them either. > > I'm only hoping when he says "Gnome", he doesn't mean anything compiled > with GTK. > > I think I read somewhere that GTK 3 was meant for gnome and gnome only. If gnome is linux only is not a problem for me. The problem is if linux becomes gnome only. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e7ab8c.8030...@rail.eu.org
Re: End of hypocrisy ?
On Sun, 10 Aug 2014 06:35:54 -0400 Tom H wrote: > Olav Vitters, a Gnome guy who always argues on behalf of Gnome/systemd > on debian-devel@ (I don't think that he's involved in Debian in any > other way), has said on his blog "it seems eventually GNOME will head > to be systemd and Linux-only" Wow, in which case Gnumeric and Gimp won't work on *BSD, and my friends with Windows or Mac won't be able to use them either. I'm only hoping when he says "Gnome", he doesn't mean anything compiled with GTK. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810132349.5b6d4...@mydesq2.domain.cxm
Re: End of hypocrisy ?
On Sun, Aug 10, 2014 at 1:15 AM, Bob Proulx wrote:
> Tom H wrote:
>> Bob Proulx wrote:
>>>
>>> I believe the point was that it should be "make before break". They
>>> should have allowed people to use systemd without preventing people
>>> from not using it. They didn't make a new system without breaking the
>>> old one. They broke the old one while trying to build the new one.
>>> That is the problem. You shouldn't burn down your old house while you
>>> are still designing and building your new house.
>>
>> Had Gnome not had to rely on systemd as pid 1, we might not have had a
>> CTTE bug, etc.
>
> But then the question becames did the GNOME 3 folks "had to rely" on
> systemd? Did they really have to do it? No. We have had a plethora
> of window managers and desktop systms for years and years and years
> without it. They didn't have to require it.
>
> I am not saying that there weren't corner cases with problems. I am
> saying that for all of those years we were apparently happy in spite
> of those corner case problems. Therefore I don't think GNOME 3 "had"
> to rely on systemd as pid 1. That is disproven by the last few
> decades without it. And somehow I think all of the happy *BSD users
> who don't have systemd will also disagree that it is a hard
> requirement.
>
> My point is that it would have been much easier if they had created a
> system that you could optionally migrate to without being *forced*
> onto it. Then if it turns out to be clearly superior people will
> desire to move to it. People would then move of their own volition
> because they would want to move to it. If they had done it that way
> it would have avoided much unpleasantness.
I wasn't disagreeing with you. I was just reminding you of the chronology.
IIRC it was the maintainer of the Gnome power applet who decided to
depend on logind. There was some pushback and his response was "I'm
the maintainer. It's my decision."
Olav Vitters, a Gnome guy who always argues on behalf of Gnome/systemd
on debian-devel@ (I don't think that he's involved in Debian in any
other way), has said on his blog "it seems eventually GNOME will head
to be systemd and Linux-only" (even when he was saying the opposite on
debian-devel@, like "we support consolekit").
So I agree with you (and I should've said so in my earlier post) that,
for jessie, sysvinit should've been the default init and those people
wanting to use systemd (or Gnome {or KDE[?]}) would've added
"init=/lib/systemd/systemd" to the kernel cmdline. The Debian systemd
maintainers could've used that extra release to integrate systemd
without the pressure of an upcoming freeze/release.
As I've said in an earlier thread, AIUI, systemd is going to be the
only init unless someone develops a dbus manager (for a standalone
udev; the way that Ubuntu developed a cgroup manager for a standalone
logind) once kdbus is in-kernel uptream and Debian compiles it into
its kernel.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAOdo=sx7jn4z37-fnom1fkz9rcxhc5kmrs2_3tqgredz8ym...@mail.gmail.com
Re: End of hypocrisy ?
Tom H wrote: > Bob Proulx wrote: > > I believe the point was that it should be "make before break". They > > should have allowed people to use systemd without preventing people > > from not using it. They didn't make a new system without breaking the > > old one. They broke the old one while trying to build the new one. > > That is the problem. You shouldn't burn down your old house while you > > are still designing and building your new house. > > Had Gnome not had to rely on systemd as pid 1, we might not have had a > CTTE bug, etc. But then the question becames did the GNOME 3 folks "had to rely" on systemd? Did they really have to do it? No. We have had a plethora of window managers and desktop systms for years and years and years without it. They didn't have to require it. I am not saying that there weren't corner cases with problems. I am saying that for all of those years we were apparently happy in spite of those corner case problems. Therefore I don't think GNOME 3 "had" to rely on systemd as pid 1. That is disproven by the last few decades without it. And somehow I think all of the happy *BSD users who don't have systemd will also disagree that it is a hard requirement. My point is that it would have been much easier if they had created a system that you could optionally migrate to without being *forced* onto it. Then if it turns out to be clearly superior people will desire to move to it. People would then move of their own volition because they would want to move to it. If they had done it that way it would have avoided much unpleasantness. Bob signature.asc Description: Digital signature
Re: journalctl and old entries [was: End of hypocrisy ?]
Ahoj, Dňa Sat, 9 Aug 2014 17:23:31 +0200 Sven Hartge napísal: > Slavko wrote: > > > Please, how i can get the records from previous boot? > > Edit /etc/systemd/journald.conf and set "Storage=persistent" > Thanks for pointing. It works :) -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: End of hypocrisy ?
On Fri, Aug 8, 2014 at 4:19 PM, Bob Proulx wrote: > Zenaan Harkness wrote: >> Joel Rees wrote: >>> >>> This is precisely why systemd should have been brought up to speed in >>> a separate, parallel, volunteer-only distro. >>> >>> (If you don't understand what I mean by a separate, parallel, >>> volunteer-only distribution, think of kfreebsd, but a little closer to >>> home.) >>> >>> I'd still say there's time for debian to go for a course correction, >> >> Seriously? >> >> What is sid for? > > I believe the point was that it should be "make before break". They > should have allowed people to use systemd without preventing people > from not using it. They didn't make a new system without breaking the > old one. They broke the old one while trying to build the new one. > That is the problem. You shouldn't burn down your old house while you > are still designing and building your new house. Had Gnome not had to rely on systemd as pid 1, we might not have had a CTTE bug, etc. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=Sy85acEdV_FtAT7BvobHjPS=f=9i-fejphuta3jeko...@mail.gmail.com
Re: journalctl and old entries [was: End of hypocrisy ?]
Slavko wrote: > Please, how i can get the records from previous boot? Edit /etc/systemd/journald.conf and set "Storage=persistent" Debians default (currently) is to just store the journal in memory which is obviously lost in reboot. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5at8375en...@mids.svenhartge.de
journalctl and old entries [was: End of hypocrisy ?]
Ahoj, Dňa Sat, 9 Aug 2014 17:22:33 +0300 Andrei POPESCU napísal: > On Vi, 08 aug 14, 20:51:14, Steve Litt wrote: > > On Fri, 8 Aug 2014 22:52:36 +0300 > > Andrei POPESCU wrote: > > > > > On Vi, 08 aug 14, 10:34:24, Steve Litt wrote: > > > > > > > > 2) Write it to the screen. Relatively little happens before the > > > >filesystem comes up, anyway. > > > > > > It's "only" about 750 lines on my laptop... > > > > How'd you count the lines? Did you use a laptop as a serial console > > or something? > > No, I just checked the output of 'journalctl -alb'. Line 751 is: I have dedicated virtual machine to test and learn systemd, but when i try to see old entries i get, e.g.: journalctl --until 17:00 -- Logs begin at So 2014-08-09 17:09:23 CEST, end at So 2014-08-09 17:10:18 CEST. -- The 17:09 is the last boot time. Then i shutdown machine (by shutdown command), "power" it again and after boot i get: journalctl --until 17:00 -- Logs begin at So 2014-08-09 17:16:20 CEST, end at So 2014-08-09 17:16:30 CEST. -- Please, how i can get the records from previous boot? regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: End of hypocrisy ?
On Vi, 08 aug 14, 20:51:14, Steve Litt wrote: > On Fri, 8 Aug 2014 22:52:36 +0300 > Andrei POPESCU wrote: > > > On Vi, 08 aug 14, 10:34:24, Steve Litt wrote: > > > > > > 2) Write it to the screen. Relatively little happens before the > > >filesystem comes up, anyway. > > > > It's "only" about 750 lines on my laptop... > > How'd you count the lines? Did you use a laptop as a serial console or > something? No, I just checked the output of 'journalctl -alb'. Line 751 is: aug 08 12:12:23 sid kernel: EXT4-fs (sda2): re-mounted. Opts: barrier=0,errors=remount-ro Hope this explains, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: End of hypocrisy ?
On 8/8/2014 9:53 PM, AW wrote: > On Fri, 8 Aug 2014 20:50:14 -0400 > Steve Litt wrote: > > > Seventh, there's 40 years of experience with text logs. Are they > > perfect? No. > > The thread that doesn't die --- misinformation all over the place, and some it > that my misinformation -- sorry 'bout that. > > Anyway, I feel prodded, so rebuttal... > > Perfect? I should definitely say not... > a decade or so of remote exploits in no particular order: > > http://www.securityfocus.com/bid/10684/discuss > http://xforce.iss.net/xforce/xfdb/43518 > http://cxsecurity.com/issue/WLB-2011020121 > http://www.securiteam.com/securitynews/5XP0K0U9GK.html > http://www.juniper.net/security/auto/vulnerabilities/vuln3498.html > http://www.linuxtoday.com/security/291801204SCRH > http://www.cvedetails.com/cve/CVE-2000-0917/ > http://securitytracker.com/id/1019105 > http://www.redhat.com/archives/linux-security/1999-November/msg00013.html > > systemd with its binary file format and buffered line to and from a service > daemon will [or should] nearly automatically take care of some very nasty > security problems that crop up from time to time... Now, imagine if the the > log > was kept in an sql database secured with a public key or password or something > dependent on the local machine, and the queries were properly escaped to > prevent sql injection - something that would only need to be done once... > > Of course all software is broken when it comes to security. However, that's > no > reason to lay down the welcome mat. > Pushed the wrong button and sent too early. And by completely changing the system, you are doing exactly that. Just because it's a service daemon does not mean there will not be security problems. And storing them in a SQL database may cure SOME security problems - but won't cure them all. And will add more problems (beyond hundreds of lines of new code). And now you're depending on the security of the SQL engine. Are you sure they are secure? Just the engine has many more LOC than the current logging facility. Which gives the potential for many more problems - both security and others. > BTW: To those complaining of Firefox's use of sqlite... > > https://en.wikipedia.org/wiki/SQLlite > > The browsers Google Chrome, Opera, Safari and the Android Browser all allow > for storing information in, and retrieving it from, a SQLite database within > the browser, using the Web SQL Database technology. Mozilla Firefox and > Mozilla > Thunderbird store a variety of configuration data (bookmarks, cookies, > contacts > etc.) in internally managed SQLite databases, and even offer an add-on to > manage SQLite databases. > > So, all major browsers except IE use sqlite. > > --Andrew > > So browsers use SQLite? They are applications, not system logging. Storing configuration data which will only be read by the application is much different than logging system messages. You are talking apples and oranges here. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e62491.1000...@attglobal.net
Re: End of hypocrisy ?
On 8/8/2014 9:53 PM, AW wrote: > On Fri, 8 Aug 2014 20:50:14 -0400 > Steve Litt wrote: > > > Seventh, there's 40 years of experience with text logs. Are they > > perfect? No. > > The thread that doesn't die --- misinformation all over the place, and some it > that my misinformation -- sorry 'bout that. > > Anyway, I feel prodded, so rebuttal... > > Perfect? I should definitely say not... > a decade or so of remote exploits in no particular order: > > http://www.securityfocus.com/bid/10684/discuss > http://xforce.iss.net/xforce/xfdb/43518 > http://cxsecurity.com/issue/WLB-2011020121 > http://www.securiteam.com/securitynews/5XP0K0U9GK.html > http://www.juniper.net/security/auto/vulnerabilities/vuln3498.html > http://www.linuxtoday.com/security/291801204SCRH > http://www.cvedetails.com/cve/CVE-2000-0917/ > http://securitytracker.com/id/1019105 > http://www.redhat.com/archives/linux-security/1999-November/msg00013.html > > systemd with its binary file format and buffered line to and from a service > daemon will [or should] nearly automatically take care of some very nasty > security problems that crop up from time to time... Now, imagine if the the > log > was kept in an sql database secured with a public key or password or something > dependent on the local machine, and the queries were properly escaped to > prevent sql injection - something that would only need to be done once... > > Of course all software is broken when it comes to security. However, that's > no > reason to lay down the welcome mat. > > BTW: To those complaining of Firefox's use of sqlite... > > https://en.wikipedia.org/wiki/SQLlite > > The browsers Google Chrome, Opera, Safari and the Android Browser all allow > for storing information in, and retrieving it from, a SQLite database within > the browser, using the Web SQL Database technology. Mozilla Firefox and > Mozilla > Thunderbird store a variety of configuration data (bookmarks, cookies, > contacts > etc.) in internally managed SQLite databases, and even offer an add-on to > manage SQLite databases. > > So, all major browsers except IE use sqlite. > > --Andrew > > So rather than fix the problems, you're suggesting replacing the current system with a different one which will not only have it's own set of problems (many more than the ones I listed - which can't be fixed), but won't necessarily fix the problems in the existing system. It makes sense - NOT! Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e6235c.8010...@attglobal.net
Re: End of hypocrisy ?
On Fri, 8 Aug 2014 20:50:14 -0400 Steve Litt wrote: > Seventh, there's 40 years of experience with text logs. Are they > perfect? No. The thread that doesn't die --- misinformation all over the place, and some it that my misinformation -- sorry 'bout that. Anyway, I feel prodded, so rebuttal... Perfect? I should definitely say not... a decade or so of remote exploits in no particular order: http://www.securityfocus.com/bid/10684/discuss http://xforce.iss.net/xforce/xfdb/43518 http://cxsecurity.com/issue/WLB-2011020121 http://www.securiteam.com/securitynews/5XP0K0U9GK.html http://www.juniper.net/security/auto/vulnerabilities/vuln3498.html http://www.linuxtoday.com/security/291801204SCRH http://www.cvedetails.com/cve/CVE-2000-0917/ http://securitytracker.com/id/1019105 http://www.redhat.com/archives/linux-security/1999-November/msg00013.html systemd with its binary file format and buffered line to and from a service daemon will [or should] nearly automatically take care of some very nasty security problems that crop up from time to time... Now, imagine if the the log was kept in an sql database secured with a public key or password or something dependent on the local machine, and the queries were properly escaped to prevent sql injection - something that would only need to be done once... Of course all software is broken when it comes to security. However, that's no reason to lay down the welcome mat. BTW: To those complaining of Firefox's use of sqlite... https://en.wikipedia.org/wiki/SQLlite The browsers Google Chrome, Opera, Safari and the Android Browser all allow for storing information in, and retrieving it from, a SQLite database within the browser, using the Web SQL Database technology. Mozilla Firefox and Mozilla Thunderbird store a variety of configuration data (bookmarks, cookies, contacts etc.) in internally managed SQLite databases, and even offer an add-on to manage SQLite databases. So, all major browsers except IE use sqlite. --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808215307.88c4e752588c245d911b9...@1024bits.com
Re: End of hypocrisy ?
Steve Litt wrote: > Andrei POPESCU wrote: > > Steve Litt wrote: > > > 2) Write it to the screen. Relatively little happens before the > > >filesystem comes up, anyway. > > > > It's "only" about 750 lines on my laptop... > > How'd you count the lines? Did you use a laptop as a serial console or > something? I don't know how Andrei counts these things but for me: # apt-get install bootlogd And then after a reboot: # wc -l /var/log/boot 103 /var/log/boot I have systems with fewer lines (84) and some with a few more lines (153). Seeing 750 lines seems excessivly many but it would all depend upon what is installed and what starts at boot time. Bob signature.asc Description: Digital signature
Re: End of hypocrisy ?
On Fri, 8 Aug 2014 22:52:36 +0300 Andrei POPESCU wrote: > On Vi, 08 aug 14, 10:34:24, Steve Litt wrote: > > > > 2) Write it to the screen. Relatively little happens before the > >filesystem comes up, anyway. > > It's "only" about 750 lines on my laptop... > > Kind regards, > Andrei How'd you count the lines? Did you use a laptop as a serial console or something? SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808205114.73ef8...@mydesq2.domain.cxm
Re: End of hypocrisy ?
On Fri, 08 Aug 2014 13:38:55 -0400 Jerry Stuckle wrote: > > Nope. First of all, messages are NOT relational, unless you are > calling the source of the message and the text of the message > relational. > > Second, there is significant additional overhead when inserting into a > SQL database vs. adding to the end of a text file. > > Third, to insert or retrieve data from the SQL database, you need the > SQL engine running. What if there is a problem with the engine? > With a text file, all you need is the file system up to add to the > file, and a command line prompt plus grep, head, tail, etc. to search > the file (vim is also a possibility but not necessary). It is also > faster to grep a text file than a SQL database unless the log file is > huge. > > Fourth, the same data in a SQL file takes up more space than in a > text file. > > Fifth, log files can easily be rotated in a text file; it is much > harder with a SQL database. Sixth, people don't move to Unix (and therefore Linux) to eschew text files. Unix and Linux were optimized to work on file systems. Seventh, there's 40 years of experience with text logs. Are they perfect? No. Could there be an API to write consistent logs from all apps? Of course: I could write it myself. I'd just need to get a specification. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808205014.2a30c...@mydesq2.domain.cxm
Re: End of hypocrisy ?
On 8/8/2014 4:16 PM, Joe wrote: > On Fri, 08 Aug 2014 13:38:55 -0400 > Jerry Stuckle wrote: > > >> >> Nope. First of all, messages are NOT relational, unless you are >> calling the source of the message and the text of the message >> relational. >> >> Second, there is significant additional overhead when inserting into a >> SQL database vs. adding to the end of a text file. >> >> Third, to insert or retrieve data from the SQL database, you need the >> SQL engine running. What if there is a problem with the engine? >> With a text file, all you need is the file system up to add to the >> file, and a command line prompt plus grep, head, tail, etc. to search >> the file (vim is also a possibility but not necessary). It is also >> faster to grep a text file than a SQL database unless the log file is >> huge. >> >> Fourth, the same data in a SQL file takes up more space than in a >> text file. >> >> Fifth, log files can easily be rotated in a text file; it is much >> harder with a SQL database. >> >> I just can't see any advantages to using a SQL database over text >> files >> > > Sixth, Microsoft does it... > LOL! Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e5365e.3070...@attglobal.net
Re: End of hypocrisy ?
Zenaan Harkness wrote: > Joel Rees wrote: > > This is precisely why systemd should have been brought up to speed in > > a separate, parallel, volunteer-only distro. > > > > (If you don't understand what I mean by a separate, parallel, > > volunteer-only distribution, think of kfreebsd, but a little closer to > > home.) > > > > I'd still say there's time for debian to go for a course correction, > > Seriously? > > What is sid for? I believe the point was that it should be "make before break". They should have allowed people to use systemd without preventing people from not using it. They didn't make a new system without breaking the old one. They broke the old one while trying to build the new one. That is the problem. You shouldn't burn down your old house while you are still designing and building your new house. Bob signature.asc Description: Digital signature
Re: End of hypocrisy ?
On Fri, 08 Aug 2014 13:38:55 -0400 Jerry Stuckle wrote: > > Nope. First of all, messages are NOT relational, unless you are > calling the source of the message and the text of the message > relational. > > Second, there is significant additional overhead when inserting into a > SQL database vs. adding to the end of a text file. > > Third, to insert or retrieve data from the SQL database, you need the > SQL engine running. What if there is a problem with the engine? > With a text file, all you need is the file system up to add to the > file, and a command line prompt plus grep, head, tail, etc. to search > the file (vim is also a possibility but not necessary). It is also > faster to grep a text file than a SQL database unless the log file is > huge. > > Fourth, the same data in a SQL file takes up more space than in a > text file. > > Fifth, log files can easily be rotated in a text file; it is much > harder with a SQL database. > > I just can't see any advantages to using a SQL database over text > files > Sixth, Microsoft does it... -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808211607.54527...@jresid.jretrading.com
Re: End of hypocrisy ?
On Vi, 08 aug 14, 10:34:24, Steve Litt wrote: > > 2) Write it to the screen. Relatively little happens before the >filesystem comes up, anyway. It's "only" about 750 lines on my laptop... Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: End of hypocrisy ?
Jerry Stuckle wrote: > Fourth, the same data in a SQL file takes up more space than in a text file. > > Fifth, log files can easily be rotated in a text file; it is much harder > with a SQL database. Also text files compress well by compressing a large block of text all at once. It is efficient to keep a long history. Rotated text files are routinely compressed. In a database it is hard to have the same level of compression. Bob signature.asc Description: Digital signature
Re: End of hypocrisy ?
On 8/8/2014 12:18 PM, Zenaan Harkness wrote: > On 8/8/14, Jerry Stuckle wrote: >> On 8/7/2014 8:28 PM, AW wrote: >>> On Fri, 8 Aug 2014 09:03:56 +0900 >>> Joel Rees wrote: >>> >>> > You do understand the chicken-and-egg nature of what you're asking >>> for? >>> > >>> > You're needing to output logs to but up servers, but you have to boot >>> > a server as complex as anySQL server to get there. >>> >>> I wasn't going to continue on this thread -- and after playing with >>> the journalctl cli for much of the day -- I repent of my complaints >>> [mostly] >>> -- any remaining complaints are extremely minor. But I guess I should >>> answer a >>> direct question... perhaps a new thread should be started, this one is >>> getting >>> long in the tooth. >>> >>> Of course I understand the chicken-egg problem. However, once the system >>> is >>> running, there's no reason why the log data collected during the boot >>> process couldn't then parsed into a standardized db --- resulting in >>> standardized sql query capabilities. The boot log data should be >>> entirely >>> ASCII until a login prompt. This greatly assists troubleshooting of >>> failed >>> boots - undeniably. However, after booting, remove the ASCII boot log >>> data >>> from RAM via secure deletion process to increase security of the system as >>> a >>> whole... >>> >>> --Andrew >>> >>> >> >> I just wonder - why should I have to look in multiple paces for >> (possibly related) messages? > > Seriously Jerry, your mind needs expanding! > You didn't answer the question. > >> That is, some to a text file, some to a SQL file. > > Of course! You just don't get it. > Exactly - why should I have to look multiple places for related messages? > Whoever does the patch to systemd will I'm sure put some > options in to send just say every second log message to the > db, and the others to the journal - for load balancing or > whatever its needed for. > What a mess! > >> I have nothing against SQL (I've been using it for over 25 years). But > > Awesome! That means you can help out with the --output=sql > patch yes? > Sure I could. But I won't. > >> I don't think it's a good solution to everything. Not everything is > > Your thinking is questionable at best. > >> relational (which is what SQL excels at). And not everything needs a > > Except for the journal's binary blob support, it is relational, > and Postgres has support for all sorts of wierd types, I'm sure > it can handle binary blobs just fine! > >> SQL engine when text files work just as well. > > Definitely wrong about that. > > Cheers > Zenaan > > Nope. First of all, messages are NOT relational, unless you are calling the source of the message and the text of the message relational. Second, there is significant additional overhead when inserting into a SQL database vs. adding to the end of a text file. Third, to insert or retrieve data from the SQL database, you need the SQL engine running. What if there is a problem with the engine? With a text file, all you need is the file system up to add to the file, and a command line prompt plus grep, head, tail, etc. to search the file (vim is also a possibility but not necessary). It is also faster to grep a text file than a SQL database unless the log file is huge. Fourth, the same data in a SQL file takes up more space than in a text file. Fifth, log files can easily be rotated in a text file; it is much harder with a SQL database. I just can't see any advantages to using a SQL database over text files Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e50b2f.2020...@attglobal.net
Re: End of hypocrisy ?
On 8/8/14, Jerry Stuckle wrote: > On 8/7/2014 8:28 PM, AW wrote: >> On Fri, 8 Aug 2014 09:03:56 +0900 >> Joel Rees wrote: >> >> > You do understand the chicken-and-egg nature of what you're asking >> for? >> > >> > You're needing to output logs to but up servers, but you have to boot >> > a server as complex as anySQL server to get there. >> >> I wasn't going to continue on this thread -- and after playing with >> the journalctl cli for much of the day -- I repent of my complaints >> [mostly] >> -- any remaining complaints are extremely minor. But I guess I should >> answer a >> direct question... perhaps a new thread should be started, this one is >> getting >> long in the tooth. >> >> Of course I understand the chicken-egg problem. However, once the system >> is >> running, there's no reason why the log data collected during the boot >> process couldn't then parsed into a standardized db --- resulting in >> standardized sql query capabilities. The boot log data should be >> entirely >> ASCII until a login prompt. This greatly assists troubleshooting of >> failed >> boots - undeniably. However, after booting, remove the ASCII boot log >> data >> from RAM via secure deletion process to increase security of the system as >> a >> whole... >> >> --Andrew >> >> > > I just wonder - why should I have to look in multiple paces for > (possibly related) messages? Seriously Jerry, your mind needs expanding! > That is, some to a text file, some to a SQL file. Of course! You just don't get it. Whoever does the patch to systemd will I'm sure put some options in to send just say every second log message to the db, and the others to the journal - for load balancing or whatever its needed for. > I have nothing against SQL (I've been using it for over 25 years). But Awesome! That means you can help out with the --output=sql patch yes? > I don't think it's a good solution to everything. Not everything is Your thinking is questionable at best. > relational (which is what SQL excels at). And not everything needs a Except for the journal's binary blob support, it is relational, and Postgres has support for all sorts of wierd types, I'm sure it can handle binary blobs just fine! > SQL engine when text files work just as well. Definitely wrong about that. Cheers Zenaan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOsGNSTLcxnj2xnm-eqzN+-Ha=vp0vd8wu-okxuqm3rdazz...@mail.gmail.com
Re: End of hypocrisy ?
On 8/8/14, Joel Rees wrote: > On Fri, Aug 8, 2014 at 12:05 AM, Brian wrote: >> On Thu 07 Aug 2014 at 16:53:10 +0300, David Baron wrote: >>> Wish there were not so many bugs around systemd. No objection to it as >>> long as >>> it works. >> >> The number of bugs on >> >> >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable >> >> doesn't seen that high for a package of its importance and visibility. >> Most reports have had a response. Some reports are not bugs. >> >> If you value a low blood pressure don't look at the bug page for apt. :) > > This is precisely why systemd should have been brought up to speed in > a separate, parallel, volunteer-only distro. > > (If you don't understand what I mean by a separate, parallel, > volunteer-only distribution, think of kfreebsd, but a little closer to > home.) > > I'd still say there's time for debian to go for a course correction, Seriously? What is sid for? I guess by that logic, the big X11 changes should have been in such a parallel debian, and the libc5->libc6 likewise? Which types of big changes should be in your proposed separate, parallel, volunteer-only (as if Debian is not) distribution? Perhaps we could call that, oh I dunno, Debian experimental? > but everyone seems to be determined to ignore the obvious. Hell no! I think we should encourage a Debian experimental distro, which is volunteer only (absolutely no paid contributors) and should be separate to sid and testing. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOsGNSQYobp9ienvd=nksbsjyr5osu5hxzxay+dqsfnm4u4...@mail.gmail.com
Re: End of hypocrisy ?
On 8/8/14, AW wrote: > On Thu, 7 Aug 2014 16:44:39 -0400 > Tom H wrote: > > > journalctl has output options: > > > > -o, --output= > > > > Controls the formatting of the journal entries that are shown. > > Takes one of the following options: > > Seems fine to me after letting go of first impression of distrust > in new things... > > However, I still like my pet idea of postgresql --- and SQL > is much more fun than journalctl statements... > > So, back to the ranch I go... Once you've got it humming, submit your patch for --output=sql to the systemd upstream. Others of us would appreciate that :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caosgnsqfwjqkfskpaepw2ytx-c7zf+qzyugejpvz-uakco6...@mail.gmail.com
Re: End of hypocrisy ?
Ahoj, Dňa Fri, 8 Aug 2014 09:33:45 -0400 Tom H napísal: > On Thu, Aug 7, 2014 at 3:12 AM, Slavko wrote: > > Dňa Wed, 6 Aug 2014 16:25:21 -0400 Tom H > > napísal: > >> > >> I've saved one or two relevant URLs from debian-devel@ pre-CTTE bug > >> thread. I can dig them up and post them if you're interested. > > > > Please, give them. > > More than two... > Thanks. I did quick look into them yet. But now i understand more. If i want to find the analogy, then i find in my mind the switch from structured programming to object oriented. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: End of hypocrisy ?
On Thu, 7 Aug 2014 20:13:08 -0700 (PDT) Rusi Mody wrote: > On Friday, August 8, 2014 5:40:01 AM UTC+5:30, Joel Rees wrote: > > You do understand the chicken-and-egg nature of what you're asking > > for? [clip] > Is the problem absent with text files? > If one wants to write a text-log one needs a text-file. > A text file exists on some file-system. Oh, come on now, the preceding assertion is a little over the top, don't you think? Every boot I've ever seen has a read/write filesystem very early in the boot. Now let's look at what you need for a binary system: 1) The same filesystem as you needed for the text log files. 2) The program to read the logs. 3) Any config that reading program might need. And, if you're putting it in Postgres, you also need: 4) A functioning Postgres (not always trivial) 5) The right Postgres user and password #5 Would be at least somewhat challenging if you were forced to boot the computer from a rescue CD, which happens to me a lot. > What of those messages that need to be logged before there are any > filesystems mounted? Several choices: 1) Keep it in RAM til you have a read-write filesystem up, then write it all. 2) Write it to the screen. Relatively little happens before the filesystem comes up, anyway. 3) Specify a bunch of CHS (Cylinder Head Sector) sectors for that purpose, cover them with a file whose whole purpose is as a placeholder, and write the info to the sectors. Later transfer them to the text log. Keep in mind, the time between when you have a read/write filesystem and the time Postgres is ready to be written is an eternity. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808103424.71065...@mydesq2.domain.cxm
Re: End of hypocrisy ?
- Original Message - > From: "Brad Rogers" > > On Thu, 7 Aug 2014 15:28:08 -0400 > Rob Owens wrote: > > Hello Rob, > > >I do miss the ability to grep my bookmarks.html file. Maybe there's a > >way to do it with sqlite, but I never learned. > > Whilst it's not as convenient as grepping a (nominally) text file, > there's a plug-in available for Ff that may be of interest to you called > SQLite Manager. > Thanks, I'll look into that. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2039362183.37922439.1407508212417.javamail.zim...@ptd.net
Re: binary data vs. text (in firefox) -- was Re: End of hypocrisy ?
- Original Message - > From: "Rob Owens" > > - Original Message - > > From: "AW" > > > > On Thu, 7 Aug 2014 15:28:08 -0400 > > Rob Owens wrote: > > > > > I do miss the ability to grep my bookmarks.html file. Maybe there's a > > > way to do it with sqlite, but I never learned. > > > > > > One thing that attracted me to Linux many years ago was that due to its > > > Unix heritage, > > > > You use the SQL language... which also has a long heritage -- I think from > > the > > 1960s... It's fairly simple to produce queries. And there's no need to > > worry > > about regex, which - IMO - is far more difficult. > > > > So -- instead of 'grep' you would use sqlite3 [dbfile] [query] > > > Thanks for the tips. I'm gonna argue with you just a bit, but I do > appreciate your advice. > > > To see what kind of things are stored in the firefox places database: > > of course your .default file will most likely be named differently... > > sqlite3 ~/.mozilla/firefox/tolgu73t.default/places.sqlite ".tables" > > > In the previous thread about systemd, I pointed out that I now need to learn > something new in order to do the same thing I've always done (as opposed to > learning something new in order to gain new capabilities). The command you > give looks simple enough, but here are the downsides from my perspective: > > 1) sqlite3 was not installed on my system (maybe that's Debian's fault). > 2) Besides sqlite3, there is also a package called sqlite. If I was trying > to figure this out on my own, without your advice, I probably would have > installed sqlite -- and that doesn't work. > 3) I need to know to search for ".tables". Maybe that's obvious to some, > but wasn't to me. > > Overall I'd say there is a greater barrier to entry for doing simple searches > with sqlite3 than with grep. Your point about regex's being complicated is > well taken, but I can grep a plain old text string easily enough. > > > and to list bookmarks: > > sqlite3 ~/.mozilla/firefox/tolgu73t.default/places.sqlite "select * from > > moz_bookmarks" > > > I ran this query, and it shows me the name of my bookmarks, but not the url. > Can you tell me where to find the urls? > > I'll also add: > > 4) I need to know sql syntax to perform this search. While sql is certainly > popular, I'd say it's not as widely known among users and sysadmins as grep > is. So the use of sqlite3 in firefox could easily be seen as unnecessary > complication. > 5) Oh yeah, and no tab completion when entering table names! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1227706561.37920737.1407508113912.javamail.zim...@ptd.net
binary data vs. text (in firefox) -- was Re: End of hypocrisy ?
- Original Message - > From: "AW" > > On Thu, 7 Aug 2014 15:28:08 -0400 > Rob Owens wrote: > > > I do miss the ability to grep my bookmarks.html file. Maybe there's a > > way to do it with sqlite, but I never learned. > > > > One thing that attracted me to Linux many years ago was that due to its > > Unix heritage, > > You use the SQL language... which also has a long heritage -- I think from > the > 1960s... It's fairly simple to produce queries. And there's no need to worry > about regex, which - IMO - is far more difficult. > > So -- instead of 'grep' you would use sqlite3 [dbfile] [query] > Thanks for the tips. I'm gonna argue with you just a bit, but I do appreciate your advice. > To see what kind of things are stored in the firefox places database: > of course your .default file will most likely be named differently... > sqlite3 ~/.mozilla/firefox/tolgu73t.default/places.sqlite ".tables" > In the previous thread about systemd, I pointed out that I now need to learn something new in order to do the same thing I've always done (as opposed to learning something new in order to gain new capabilities). The command you give looks simple enough, but here are the downsides from my perspective: 1) sqlite3 was not installed on my system (maybe that's Debian's fault). 2) Besides sqlite3, there is also a package called sqlite. If I was trying to figure this out on my own, without your advice, I probably would have installed sqlite -- and that doesn't work. 3) I need to know to search for ".tables". Maybe that's obvious to some, but wasn't to me. Overall I'd say there is a greater barrier to entry for doing simple searches with sqlite3 than with grep. Your point about regex's being complicated is well taken, but I can grep a plain old text string easily enough. > and to list bookmarks: > sqlite3 ~/.mozilla/firefox/tolgu73t.default/places.sqlite "select * from > moz_bookmarks" > I ran this query, and it shows me the name of my bookmarks, but not the url. Can you tell me where to find the urls? I'll also add: 4) I need to know sql syntax to perform this search. While sql is certainly popular, I'd say it's not as widely known among users and sysadmins as grep is. So the use of sqlite3 in firefox could easily be seen as unnecessary complication. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2071324850.37901984.1407507535981.javamail.zim...@ptd.net
Re: End of hypocrisy ?
On Thu, Aug 7, 2014 at 3:12 AM, Slavko wrote: > Dňa Wed, 6 Aug 2014 16:25:21 -0400 Tom H napísal: >> >> I've saved one or two relevant URLs from debian-devel@ pre-CTTE bug >> thread. I can dig them up and post them if you're interested. > > Please, give them. More than two... I'd intended to re-read them and possibly not post them all but I haven't had the time to do so . Russ Allberry https://lists.debian.org/debian-devel/2012/02/msg00911.html https://lists.debian.org/debian-devel/2012/02/msg01079.html https://lists.debian.org/debian-devel/2012/04/msg00638.html https://lists.debian.org/debian-devel/2013/07/msg00456.html Ben Hutchings https://lists.debian.org/debian-devel/2012/05/msg00263.html Roger Leigh (sysvinit developer) https://lists.debian.org/debian-devel/2012/05/msg00267.html Petter Reinholdtsen (sysvinit developer) https://lists.debian.org/debian-devel/2012/02/msg01043.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=SzEOmZOQewFK7yvEpWEEwh815hbBGrH_OX2s9k=t...@mail.gmail.com
Re: End of hypocrisy ?
On Thu, Aug 07, 2014 at 10:21:04AM -0700, Rusi Mody wrote: > On Thursday, August 7, 2014 7:40:02 PM UTC+5:30, Steve Litt wrote: > > I don't necessarily disagree, but I very strongly believe its first > > step should be to go to a text file with one line per event, or perhaps > > some sublines. If that text file were designed correctly, perhaps with > > field separators, it would be trivial to write a C or Python program to > > input it into Postgres. I just want to make sure that I can read that > > log on any Linux, BSD, or even (ugh) Mac and Windows. > > Two examples come to mind > > 1. Firefox sometime (around version 4??) switched from storing > bookmarks in a half-cooked html file to sqlite. There > was a riot. The devs however went ahead and switched not just > bookmarks but history and other stuff also. Has firefox been the > worse for it?? Yup! I've got a strange issue accessing a site. Starting in safe mode makes no difference. If I use a brand new profile I can access it fine! If I spend ages making the new profile like the existing one, and this issue somehow recurs I'm back at square one. :( -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808120330.GD2128@tal
Re: End of hypocrisy ?
On Friday, August 8, 2014 5:40:01 AM UTC+5:30, Joel Rees wrote: > On Fri, Aug 8, 2014 at 6:19 AM, AW wrote: > > On Thu, 7 Aug 2014 16:44:39 -0400 > > Tom H wrote: > > > journalctl has output options: > > > -o, --output= > > > Controls the formatting of the journal entries that are shown. Takes > > > one of the following options: > > Seems fine to me after letting go of first impression of distrust in new > > things... > > However, I still like my pet idea of postgresql --- and SQL is much more fun > > than journalctl statements... > > So, back to the ranch I go... > You do understand the chicken-and-egg nature of what you're asking for? > You're needing to output logs to but up servers, but you have to boot > a server as complex as anySQL server to get there. Where is anySQL > going to log its progress as it boots up, not to mention that the > system itself has to wait for anySQL to get up before it can do > anything that might generate a log. > (Having a separate machine be a log server can be useful, but even > that can't take log messages when the network is not properly up. > Which means there will be low-level log messages kept in a separate > place, and sometimes high-level log messages waiting to be off-loaded > to the log server.) Yes circular definition is a problem. And it is ubiquitous and central to our field: http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html So... yes an SQL-based log system will need logs itself. Should it (try to) to log itself? Is the problem absent with text files? If one wants to write a text-log one needs a text-file. A text file exists on some file-system. What of those messages that need to be logged before there are any filesystems mounted? This is not academic: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698751 [Not sure of the status of the bug] -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/391fa0aa-b7d9-450e-a492-8ebdfc4df...@googlegroups.com
Re: End of hypocrisy ?
On 8/7/2014 8:28 PM, AW wrote: > On Fri, 8 Aug 2014 09:03:56 +0900 > Joel Rees wrote: > > > You do understand the chicken-and-egg nature of what you're asking for? > > > > You're needing to output logs to but up servers, but you have to boot > > a server as complex as anySQL server to get there. > > I wasn't going to continue on this thread -- and after playing with > the journalctl cli for much of the day -- I repent of my complaints [mostly] > -- any remaining complaints are extremely minor. But I guess I should answer a > direct question... perhaps a new thread should be started, this one is getting > long in the tooth. > > Of course I understand the chicken-egg problem. However, once the system is > running, there's no reason why the log data collected during the boot > process couldn't then parsed into a standardized db --- resulting in > standardized sql query capabilities. The boot log data should be entirely > ASCII until a login prompt. This greatly assists troubleshooting of failed > boots - undeniably. However, after booting, remove the ASCII boot log data > from RAM via secure deletion process to increase security of the system as a > whole... > > --Andrew > > I just wonder - why should I have to look in multiple paces for (possibly related) messages? That is, some to a text file, some to a SQL file. I have nothing against SQL (I've been using it for over 25 years). But I don't think it's a good solution to everything. Not everything is relational (which is what SQL excels at). And not everything needs a SQL engine when text files work just as well. Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e425d1.8080...@attglobal.net
Re: End of hypocrisy ?
On Fri, 8 Aug 2014 09:03:56 +0900 Joel Rees wrote: > You do understand the chicken-and-egg nature of what you're asking for? > > You're needing to output logs to but up servers, but you have to boot > a server as complex as anySQL server to get there. I wasn't going to continue on this thread -- and after playing with the journalctl cli for much of the day -- I repent of my complaints [mostly] -- any remaining complaints are extremely minor. But I guess I should answer a direct question... perhaps a new thread should be started, this one is getting long in the tooth. Of course I understand the chicken-egg problem. However, once the system is running, there's no reason why the log data collected during the boot process couldn't then parsed into a standardized db --- resulting in standardized sql query capabilities. The boot log data should be entirely ASCII until a login prompt. This greatly assists troubleshooting of failed boots - undeniably. However, after booting, remove the ASCII boot log data from RAM via secure deletion process to increase security of the system as a whole... --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807202843.e51133aa06266a9b5...@1024bits.com
Re: End of hypocrisy ?
On Fri, Aug 8, 2014 at 6:19 AM, AW wrote: > On Thu, 7 Aug 2014 16:44:39 -0400 > Tom H wrote: > > > journalctl has output options: > > > > -o, --output= > > > > Controls the formatting of the journal entries that are shown. Takes > > one of the following options: > > Seems fine to me after letting go of first impression of distrust in new > things... > > However, I still like my pet idea of postgresql --- and SQL is much more fun > than journalctl statements... > > So, back to the ranch I go... You do understand the chicken-and-egg nature of what you're asking for? You're needing to output logs to but up servers, but you have to boot a server as complex as anySQL server to get there. Where is anySQL going to log its progress as it boots up, not to mention that the system itself has to wait for anySQL to get up before it can do anything that might generate a log. (Having a separate machine be a log server can be useful, but even that can't take log messages when the network is not properly up. Which means there will be low-level log messages kept in a separate place, and sometimes high-level log messages waiting to be off-loaded to the log server.) There is a fundamental bug in ASCII/Unicode that is causing this technical angst. Well, there are some misfeatures of Unicode, and there are some inherent shortcomings in any character encoding, and they converge to cause the sort of problems that are being discussed here. If we can get package developers to be more considerate of common log formats when they write their log messages, that will help. But the systemd crew don't want to work that hard, so they are unilaterally pushing a common (binary API) log format on the whole world. And, as a sometimes programmer, I can tell you I'll often be ignoring the systemd logging system. I've been made non-productive often enough by having to fight with mandated java logging classes that just don't quite fit the kind of log I need to write. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43inw9v5v5i2qgj+r35yuyh+e+y3nr711xrczej3fba9...@mail.gmail.com
Re: End of hypocrisy ?
On Fri, Aug 8, 2014 at 12:05 AM, Brian wrote: > On Thu 07 Aug 2014 at 16:53:10 +0300, David Baron wrote: > >> On Thursday 07 August 2014 14:21:45 Brian wrote: >> > >> > This is part of the transition to systemd plan. >> > >> > https://lists.debian.org/87mwc9gfsw@xoog.err.no >> > >> > Also, for those who care, libpam-systemd's Depends: line now has >> > >> > systemd-sysv | systemd-shim >> >> Should the dsf-53.3 versions be installed or does it matter? >> systemd-shim is NOT installed (had installed on previous 32 bit system as I >> said). Or are these obsolete, being handled by systemd-sysv so can/should be >> removed or does it matter? > > The transition hasn't been completed yet, I'd install and hold off any > tidying until it has been and you remain a happy camper. The neat > fallback SysV init binary feature of sysvinit might be something you > want to keep. > >> Wish there were not so many bugs around systemd. No objection to it as long >> as >> it works. > > The number of bugs on > >https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable > > doesn't seen that high for a package of its importance and visibility. > Most reports have had a response. Some reports are not bugs. > > If you value a low blood pressure don't look at the bug page for apt. :) This is precisely why systemd should have been brought up to speed in a separate, parallel, volunteer-only distro. (If you don't understand what I mean by a separate, parallel, volunteer-only distribution, think of kfreebsd, but a little closer to home.) I'd still say there's time for debian to go for a course correction, but everyone seems to be determined to ignore the obvious. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43im+qzfhwzzvou3jggsmb99yyktggw-ma66-0z6quwu...@mail.gmail.com
Re: End of hypocrisy ?
On Thu, 7 Aug 2014 16:44:39 -0400 Tom H wrote: > journalctl has output options: > > -o, --output= > > Controls the formatting of the journal entries that are shown. Takes > one of the following options: Seems fine to me after letting go of first impression of distrust in new things... However, I still like my pet idea of postgresql --- and SQL is much more fun than journalctl statements... So, back to the ranch I go... --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807171946.5f4de53e9e7f2c73cf201...@1024bits.com
Re: End of hypocrisy ?
On Thu, Aug 7, 2014 at 11:49 AM, AW wrote: > On Thu, 7 Aug 2014 16:19:03 +0100 > Darac Marjal wrote: > > > Consider it to be another database format. You wouldn't necessarily try > > to cat a MySQL or PostgreSQL datastore; you'd use the appropriate tools > > to select all from it. > > Yes. But it's not. Although it should and could be an easily queried data > store. > ... > SYSLOG_IDENTIFIER=apache2 > _PID=1808 > _COMM=apache2 > _CMDLINE=/bin/sh /etc/init.d/apache2 start > _SYSTEMD_CGROUP=/system.slice/apache2.service > _SYSTEMD_UNIT=apache2.service > MESSAGE=. > Thu 2014-08-07 06:21:24.805036 EDT [...] > PRIORITY=6 > _UID=0 > _GID=0 > ... > > This is filled with problems and pitfalls. And the outputted text from the > data store search tool is terribly formatted for further inclusion with other > regular GNU/Linux command line text processing tools. I would say, systemd > and > journald are a great start to a great end -- but right now, it's not so much > fun... journalctl has output options: -o, --output= Controls the formatting of the journal entries that are shown. Takes one of the following options: short is the default and generates an output that is mostly identical to the formatting of classic syslog files, showing one line per journal entry. short-iso is very similar, but shows ISO 8601 wallclock timestamps. short-precise is very similar, but shows timestamps with full microsecond precision. short-monotonic is very similar, but shows monotonic timestamps instead of wallclock timestamps. verbose shows the full-structured entry items with all fields. export serializes the journal into a binary (but mostly text-based) stream suitable for backups and network transfer (see Journal Export Format for more information). json formats entries as JSON data structures, one per line (see Journal JSON Format for more information). json-pretty formats entries as JSON data structures, but formats them in multiple lines in order to make them more readable by humans. json-sse formats entries as JSON data structures, but wraps them in a format suitable for Server-Sent Events. cat generates a very terse output, only showing the actual message of each journal entry with no metadata, not even a timestamp. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=Szsd2R4nozcB72E0mPjSu5jJMwToF05d7YPXLz89Z=p...@mail.gmail.com
Re: End of hypocrisy ?
On Thu, 7 Aug 2014 15:28:08 -0400 Rob Owens wrote: Hello Rob, >I do miss the ability to grep my bookmarks.html file. Maybe there's a >way to do it with sqlite, but I never learned. Whilst it's not as convenient as grepping a (nominally) text file, there's a plug-in available for Ff that may be of interest to you called SQLite Manager. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" Well you tried it just the once and found it alright for kicks Orgasm Addict - Buzzcocks signature.asc Description: PGP signature
Re: End of hypocrisy ?
On Thu, 7 Aug 2014 16:19:03 +0100 Darac Marjal wrote: > On Thu, Aug 07, 2014 at 10:01:41AM -0400, Steve Litt wrote: > > > I don't necessarily disagree, but I very strongly believe its first > > step should be to go to a text file with one line per event, or > > perhaps some sublines. If that text file were designed correctly, > > perhaps with field separators, it would be trivial to write a C or > > Python program to input it into Postgres. I just want to make sure > > that I can read that log on any Linux, BSD, or even (ugh) Mac and > > Windows. > > You see, though, this isn't the design goal of the journal. That's nice. Of course, it *is* the desired log file of a plurality or majority of Linux users who care about log files. > The > journal is designed to be resistant against corruption (hashes are > used to preserve message integrity), quick to access (there is an > index so you don't have to spool through the whole file looking for > the event that happened at 10:00, say) and well defined (times, for > example, are defined as µsec since the epoch, not some > lets-defined-another-parser text string). Yeah, to free the log-using user from the need to use head, tail, grep and cut, let's define yet another database structure. I mean, really, it's easy as pie to define the tables and relationships of a database, but world-shakingly difficult to do things like use a usec timestamp. So, if a log-using user can't read his log files with just any old rescue CD, well, that's a small price to pay for the coolness of having your log files in a database. > > Consider it to be another database format. You wouldn't necessarily > try to cat a MySQL or PostgreSQL datastore; you'd use the appropriate > tools to select all from it. In a similar vein, you'd use journalctl > to select all the entries from the journal file and you'd expect it > to do much of the hard work such as telling you if a line has been > altered (either tampered or simply corrupted), adjusting the > timestamps for time zones and so on. > > "cat"ing the journal doesn't have to lose information, either. > Journalctl can export as JSON or a serialised "export" format > (plain-text). And plain-text, as long as it's halfway sane, was all I was asking for in my initial post, always assuming it can be easily set to export and keep exporting persistent text log files. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807155651.2746f...@mydesq2.domain.cxm
Re: End of hypocrisy ?
On Thu, 7 Aug 2014 15:28:08 -0400 Rob Owens wrote: > I do miss the ability to grep my bookmarks.html file. Maybe there's a > way to do it with sqlite, but I never learned. > > One thing that attracted me to Linux many years ago was that due to its > Unix heritage, You use the SQL language... which also has a long heritage -- I think from the 1960s... It's fairly simple to produce queries. And there's no need to worry about regex, which - IMO - is far more difficult. So -- instead of 'grep' you would use sqlite3 [dbfile] [query] To see what kind of things are stored in the firefox places database: of course your .default file will most likely be named differently... sqlite3 ~/.mozilla/firefox/tolgu73t.default/places.sqlite ".tables" and to list bookmarks: sqlite3 ~/.mozilla/firefox/tolgu73t.default/places.sqlite "select * from moz_bookmarks" If try this, you'll notice that the output looks 'nice' -- in that it seems quite 'grep-able' ... And that's what's sorely missing from journald. --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807155547.a93095d9b778479c97a04...@1024bits.com
Re: End of hypocrisy ?
On Thursday, August 7, 2014 7:40:02 PM UTC+5:30, Steve Litt wrote: > I don't necessarily disagree, but I very strongly believe its first > step should be to go to a text file with one line per event, or perhaps > some sublines. If that text file were designed correctly, perhaps with > field separators, it would be trivial to write a C or Python program to > input it into Postgres. I just want to make sure that I can read that > log on any Linux, BSD, or even (ugh) Mac and Windows. Two examples come to mind 1. Firefox sometime (around version 4??) switched from storing bookmarks in a half-cooked html file to sqlite. There was a riot. The devs however went ahead and switched not just bookmarks but history and other stuff also. Has firefox been the worse for it?? 2. 10-15 years ago windows was famous for 'corrupted registry' The linux fan-boys of the time would proclaim: 'Aah! Windows! In linux theres no such problem!' Now whats the linux equivalent of the registry? Its /etc -- nics, nacs, bits, pieces and random stuff thrown around [Just hear the word 'etc'] But the windows devs did not listen. Instead in XP they tightened the bolts on the registry -- multi-levelled backups and what not. When is the last you've heard of a windows registry corrupted? So no speaking as a CS-ist, structuring is good unstructured is bad. and text is the limit of unstructured. Hear Alan Perlis: | The string is a stark data structure and everywhere it is passed | there is much duplication of process. | It is a perfect vehicle for hiding information. However speaking as an ordinary user my machine is quasi broken right now thanks to systemd :-) [No time/leisure to chase that right now] Is it bad design or teething troubles??? We shall see... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a11a6899-6b37-41b6-a803-2d3c6caf6...@googlegroups.com
Re: End of hypocrisy ?
On Thu 07 Aug 2014 at 18:41:24 +0300, David Baron wrote: > On Thursday 07 August 2014 16:05:40 Brian wrote: > > The number of bugs on > > > >https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable > > > > doesn't seen that high for a package of its importance and visibility. > > Most reports have had a response. Some reports are not bugs. > > > > If you value a low blood pressure don't look at the bug page for apt. > > When apt gets crippled, happened often enough, so I could not upgrade (stay > out of trouble?). Can always go to debian.org, get a needed fixed package and > use dpkg. Been there, done that. System remained bootable and usable. It's very easy to always have a bootable, usable system if systemd is the default init system. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807160519.gy19...@copernicus.demon.co.uk
Re: End of hypocrisy ?
On Thu, 7 Aug 2014 16:19:03 +0100 Darac Marjal wrote: > Consider it to be another database format. You wouldn't necessarily try > to cat a MySQL or PostgreSQL datastore; you'd use the appropriate tools > to select all from it. Yes. But it's not. Although it should and could be an easily queried data store. ... SYSLOG_IDENTIFIER=apache2 _PID=1808 _COMM=apache2 _CMDLINE=/bin/sh /etc/init.d/apache2 start _SYSTEMD_CGROUP=/system.slice/apache2.service _SYSTEMD_UNIT=apache2.service MESSAGE=. Thu 2014-08-07 06:21:24.805036 EDT [...] PRIORITY=6 _UID=0 _GID=0 ... This is filled with problems and pitfalls. And the outputted text from the data store search tool is terribly formatted for further inclusion with other regular GNU/Linux command line text processing tools. I would say, systemd and journald are a great start to a great end -- but right now, it's not so much fun... --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807114954.3678a20b9ce03c4af75dd...@1024bits.com
Re: End of hypocrisy ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/07/2014 11:19 AM, Darac Marjal wrote: > On Thu, Aug 07, 2014 at 10:01:41AM -0400, Steve Litt wrote: >> Oh geez, I'm sorry, I thought your post was flippant sarcasm, so I >> did what I thought was extending it. OK, you really do mean the log >> should go into Postgres. >> >> I don't necessarily disagree, but I very strongly believe its first >> step should be to go to a text file with one line per event, or >> perhaps some sublines. If that text file were designed correctly, >> perhaps with field separators, it would be trivial to write a C or >> Python program to input it into Postgres. I just want to make sure >> that I can read that log on any Linux, BSD, or even (ugh) Mac and >> Windows. > > You see, though, this isn't the design goal of the journal. It should be, if not "the" design goal, then certainly "a" design goal. The canonical forms of the legacy log formats (plain text) can be read and manipulated by generic tools, in any environment; if the journal cannot provide the same (with respect to its canonical data files, not to something it can export to), that's a regression from the legacy feature set. For fundamental, low-level system components (from the kernel on up), no regression is acceptable, ever. At most, one may be an unavoidable, undesirable side effect of something which is itself absolutely necessary - and even there, that only works as "choosing the lesser of two evils", which is not how those developing and advocating journald et al. seem to consider it. > The journal is designed to be resistant against corruption (hashes > are used to preserve message integrity), quick to access (there is an > index so you don't have to spool through the whole file looking for > the event that happened at 10:00, say) and well defined (times, for > example, are defined as µsec since the epoch, not some > lets-defined-another-parser text string). > > Consider it to be another database format. You wouldn't necessarily > try to cat a MySQL or PostgreSQL datastore; you'd use the appropriate > tools to select all from it. In a similar vein, you'd use journalctl > to select all the entries from the journal file and you'd expect it > to do much of the hard work such as telling you if a line has been > altered (either tampered or simply corrupted), adjusting the > timestamps for time zones and so on. Approached from that angle, I don't inherently have a problem with the journal's being stored (optionally and/or partly) as binary files. (Though I don't necessarily want automatic timestamp adjustment and so forth; I may very well want verbatim logs, for one reason or another.) However, I do still have the problem that the tools used to interact with those files are dedicated, "proprietary", single-purpose tools. Nothing other than journald uses the journal's file format; by contrast, many, many databases use the Postgres format(s), and though I'm not familiar with Postgres in any detail, it wouldn't in the least bit surprise me if there were non-Postgres-project tools which can read and/or manipulate those formats. I'm sure there are advantages to using a designed, dedicated format for the specific purpose at hand, and writing tools to work specifically with that format. I simply believe that those advantages almost inherently cannot outweigh the matching downsides of using / requiring special-purpose tools and formats. If the journal's file format became vaguely standardized and came to be used for other purposes (e.g. perhaps as a generic indexing / metadata format, if that might be suitable?), I'd have much less problem with its being used for storing and handling log messages in and by the journal. The dedicated, and apparently OS-specific (?), nature of the format and its tools is IMO a problem all of its own. > "cat"ing the journal doesn't have to lose information, either. > Journalctl can export as JSON or a serialised "export" format > (plain-text). But those aren't the journal itself, they're exports of the journal; they don't provide the journal's full functionality. (Otherwise, it would be more appropriate for the journal to use those file formats natively, rather than using binary natively and treating those formats as exports.) And accessing them from zero still requires you to have a functioning special-purpose tool (journalctl) in your available environment, which is something the legacy systems never did. Debian apparently presently avoids (or at least minimizes) this latter problem by exporting to plain-text logs by default, and never storing the binary journal files anywhere on-disk. That doesn't eliminate the underlying issue, though. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJT4556AAoJEASpNY00KDJry3wP/3i+SPOXEDTCNSb
Re: End of hypocrisy ?
On Thursday 07 August 2014 16:05:40 Brian wrote: > The number of bugs on > >https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable > > doesn't seen that high for a package of its importance and visibility. > Most reports have had a response. Some reports are not bugs. > > If you value a low blood pressure don't look at the bug page for apt. When apt gets crippled, happened often enough, so I could not upgrade (stay out of trouble?). Can always go to debian.org, get a needed fixed package and use dpkg. Been there, done that. System remained bootable and usable. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5590708.I8SyeEeI5U@dovidhalevi
Re: End of hypocrisy ?
On Thu 07 Aug 2014 at 16:53:10 +0300, David Baron wrote: > On Thursday 07 August 2014 14:21:45 Brian wrote: > > > > This is part of the transition to systemd plan. > > > > https://lists.debian.org/87mwc9gfsw@xoog.err.no > > > > Also, for those who care, libpam-systemd's Depends: line now has > > > > systemd-sysv | systemd-shim > > Should the dsf-53.3 versions be installed or does it matter? > systemd-shim is NOT installed (had installed on previous 32 bit system as I > said). Or are these obsolete, being handled by systemd-sysv so can/should be > removed or does it matter? The transition hasn't been completed yet, I'd install and hold off any tidying until it has been and you remain a happy camper. The neat fallback SysV init binary feature of sysvinit might be something you want to keep. > Wish there were not so many bugs around systemd. No objection to it as long > as > it works. The number of bugs on https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable doesn't seen that high for a package of its importance and visibility. Most reports have had a response. Some reports are not bugs. If you value a low blood pressure don't look at the bug page for apt. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807150540.gx19...@copernicus.demon.co.uk
Re: End of hypocrisy ?
On Thu, 7 Aug 2014 08:31:02 -0400 AW wrote: > On Thu, 7 Aug 2014 00:38:16 -0400 > Steve Litt wrote: > > > Software As A Service, with Web 2.0 > ... > > suggest a Google-hosted service > > Actually this is precisely the opposite of my suggestion. Using an > externally stored database as I have listed would remove the need for > an external provider, such as Google, for things like 'analytics'... > and using a standards based sql package would allow extreme detail to > be stored with very little effort. Once there exists a database of > the information, there is no reason to store that database on the > host. Although there is no reason why it couldn't remain there as > well. The advantage of remote log storing and querying would remain > even for a small 2 or 3 host home network. If this was a common > GNU/Linux package, open source routers, like buffalo, could include > the ability to collect log information from hosts and email a local > client if a host log indicates compromise --- thus perhaps > preventing, and/or early detection of, problems like the Bitcoin > mining botnet running on poorly configured but also open source NAS > boxes, like Synology. > > Seriously, if all logging is going to be dumped into a central binary > -- it would be much more useful to dump the data into something that > is logically searchable and can be scripted easily from bash using > very simple: > > pgsql -c "select $foo" > > statements. Systemd does this as is [almost]... but the command set > to query the data is definitely not standard, nor easily > discoverable. An sql query-able database makes much more sense. And > it could be sqlite rather than postgresql. > > --Andrew Oh geez, I'm sorry, I thought your post was flippant sarcasm, so I did what I thought was extending it. OK, you really do mean the log should go into Postgres. I don't necessarily disagree, but I very strongly believe its first step should be to go to a text file with one line per event, or perhaps some sublines. If that text file were designed correctly, perhaps with field separators, it would be trivial to write a C or Python program to input it into Postgres. I just want to make sure that I can read that log on any Linux, BSD, or even (ugh) Mac and Windows. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807100141.4abad...@mydesq2.domain.cxm
Re: End of hypocrisy ?
On Tue, 05 Aug 2014 23:43:09 +0300 David Baron wrote: > Seems I got it with > the new 64bit installation, wheezy upgraded to Sid. On Thu, 07 Aug 2014 15:03:50 +0300 David Baron wrote: > Offered for upgrade today are a bunch of old-style?? init components, > initscripts, sysv-rc, etc Are these the Sid installation upgrades? I generally run 'testing' on most of personal machines. I've had no issues with converting from sysvinit to systemd. Also, I've had no problems using both 'old' style init and 'new' style systemctl commands interchangeably to interact with services. --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807083108.c91fd61b715ef11d40071...@1024bits.com
Re: End of hypocrisy ?
... and the plot thickens ... Offered for upgrade today are a bunch of old-style?? init components, initscripts, sysv-rc, etc. Interesting bug-entries: Initscripts -- treat separate /usr like / paralleling entries for initramfs tools, nothing recent ins sysv... stuff. Still relevant? Relationship to systemd? Should I move /usr before upgrading initscripts? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2901574.MmjfxkVCl2@dovidhalevi
Re: End of hypocrisy ?
Ahoj, Dňa Wed, 6 Aug 2014 16:25:21 -0400 Tom H napísal: > This is from an email by Lennart: > > /var/log/messages is *very* badly designed: (snip) > It's so bad, that rsyslog upstream even suggests not to use these > files anymore, but write them in a more modern formatting that leaves > a bit more information in (such as iso timestamps). But you know > what? If you do that than all your compatibility is gone too. Yes, it sounds all as the good reason. > The interesting things is that "journalctl" is *better* at generating > the same text stream that is normally contained in /var/log/messages > than /var/log/messages itself is. "journalctl" can stuff more > information into it then /var/log/messages. And how does that happen? > Because we have more data around. We can agument the ouput with colors > (indicating priorities), we can add additional informational separator > lines (indicating reboots), we can add add in fields that aren't there > (such as the tag from the comm field, or the PID). We can timezone > correct the timestamps (because we have UTC times). And we can filter > by any of the fields, securely. > > So, yeah, /var/log/messages sucks, and journalctl is better at > generating a compatible output that that file ever was in itself. > > I didn't save the URL :( No problem here. > > Then what are advantages of the systemd? I see only disadvantages... > > I've saved one or two relevant URLs from debian-devel@ pre-CTTE bug > thread. I can dig them up and post them if you're interested. Please, give them. > Personally, I don't care. It's what I have to use so I've learned > about it and I'm using it. End of story. It is your opinion and it good for you. But people differs - i cannot accept something, only because someone develop it. I need to decide, if this software (change, etc) is good for me (to compare advantages and disadvantages, if any and then to decide). You provided good description, thanks! But more and more it seems, that the systemd (and related daemons) can provide very good things for large networks (100 server mentioned elsewhere), but it sounds as the too heavy for small networks. Too heavy not in mean of the requirements (which i don't want to discuss here), but too heavy in provided capabilities. Simple, i see usability of only small part of it (for me) and then it sounds as wasting resources. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: End of hypocrisy ?
On Wed, 6 Aug 2014 16:26:20 -0400 AW wrote: > On Wed, 6 Aug 2014 22:15:08 +0300 > Andrei POPESCU wrote: > > > The advantage of journald is that it captures more information > > because it runs much earlier and also because it captures stdin > > (?!) and stderr of daemons. The data has more metadata and is also > > better structured and indexed (hence the need for binary storage). > > I've seen this... However, I would prefer to take it several steps > farther, and store the log data in a database; postgresql, of course, > is there any other? ... Think of this powerful use case: given a > server farm of 1000 or so hosts. Each server has a write only ssl > connection to an external postgresql database for log purposes. Of > course copies of the logs can be kept locally, but think of the > security increase of not storing apache, mail, or even auth logs > locally. And think of the standardization that would come almost by > default. With a few well chosen queries, and a little R magic, the > entire 1000 host server farm could be evaluated quickly in a report > style that even management might understand... > > /sarc Perhaps this functionality is already built into systemd... > and we'd never know until we look through the header files in the > source code, and discover that - Yes! - journalctl > REMOTE_LOGGING=2.5 means activate the secure remote pgsql > capability... /sarc I think you're on the right track Andrew. What we need is to make all log files Software As A Service, with Web 2.0, so we can not only query postgres for our server logs, but we can do it from any place in the world. I suggest a Google-hosted service, because Google can supply the search capabilities necessary so we can compare and contrast our servers against those of others, and friend those with similar setups. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807003816.37211...@mydesq2.domain.cxm
Re: End of hypocrisy ?
On Thu, Aug 7, 2014 at 5:26 AM, AW wrote: > On Wed, 6 Aug 2014 22:15:08 +0300 > Andrei POPESCU wrote: > > > The advantage of journald is that it captures more information because > > it runs much earlier and also because it captures stdin (?!) and stderr > > of daemons. The data has more metadata and is also better structured and > > indexed (hence the need for binary storage). > > I've seen this... However, I would prefer to take it several steps farther, > and > store the log data in a database; postgresql, of course, is there any > other? I'm trying to pick my jaw back up off the floor. Although, in my way of thinking, it makes as much sense as most of systemd. (Do I hear a whoosh? I could imagine I'm hearing a whoosh.) > ... Think of this powerful use case: given a server farm of 1000 or so > hosts. Each server has a write only ssl connection to an external postgresql > database for log purposes. Of course copies of the logs can be kept locally, > but think of the security increase of not storing apache, mail, or even auth > logs locally. And think of the standardization that would come almost by > default. With a few well chosen queries, and a little R magic, the entire > 1000 > host server farm could be evaluated quickly in a report style that even > management might understand... > > /sarc Perhaps this functionality is already built into systemd... and we'd > never know until we look through the header files in the source code, and > discover that - Yes! - journalctl REMOTE_LOGGING=2.5 means activate the > secure > remote pgsql capability... /sarc Whew. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOHPh4EdSymLLN8R8Rzrn9Zj-RSVw=hfmh-tz9ehmt...@mail.gmail.com
Re: [OT] Floppies [was: Re: End of hypocrisy, beginning of reason]
Miles Fidelman wrote: > Doug wrote: > >Steve Litt wrote: > > > Screw that! I'm buying an old Kaypro 2x on Ebay, and using CPM for the > > > rest of my life! > > > :-) > > > >Good luck finding floppies! > > Turns out that is a big problem in maintaining the first generation of > electronic voting machines. Just saw an article about how they use the BIG > floppies. Since this is already marked OT I feel okay posting this drift: Minutes shocked to find 8-inch floppies drive nuclear deterrent http://arstechnica.com/information-technology/2014/04/60-minutes-shocked-to-find-8-inch-floppies-drive-nuclear-deterrent/ Meanwhile I am hoping they are smart enough not to update the hardware. That older hardware can't be connect to Internet and can't be hacked, cracked, or catch viruses as currently implemented. Old dedicated hardware like that is safer that way. Bob P.S. I still have at least one 8-inch floppy disk. It contains a bunch of my old assembly language programs. No drive to read it now though. :-) signature.asc Description: Digital signature
[OT] Floppies [was: Re: End of hypocrisy, beginning of reason]
Doug wrote: On 08/06/2014 09:05 AM, Steve Litt wrote: On Tue, 5 Aug 2014 16:51:03 -0400 Tom H wrote: On Tue, Aug 5, 2014 at 3:44 PM, Steve Litt wrote: LOL, perhaps I'll boot to bin/bash, and then run a script to do everything else. Oh wait, I can't do that: I hear PAM now depends on systemd, for what reason I haven't a clue. Maybe you should look into adapting the Android Init Language :) Screw that! I'm buying an old Kaypro 2x on Ebay, and using CPM for the rest of my life! :-) SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance Good luck finding floppies! Turns out that is a big problem in maintaining the first generation of electronic voting machines. Just saw an article about how they use the BIG floppies. Miles Fidelman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e2a4ca.1080...@meetinghouse.net
Re: End of hypocrisy ?
On Wed, Aug 6, 2014 at 4:27 PM, AW wrote: > On Wed, 6 Aug 2014 16:25:21 -0400 > Tom H wrote: >> >> So, yeah, /var/log/messages sucks, and journalctl is better at >> generating a compatible output that that file ever was in itself. > > I definitely agree. FTR, it was a quote. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=sxaf6wahj4ltmdop6ry5npynnv9rj9getpzbu-_zzk...@mail.gmail.com
Re: End of hypocrisy ?
On 08/06/2014 09:03 AM, Steve Litt wrote: On Tue, 05 Aug 2014 23:43:09 +0300 David Baron wrote: An amazing amount of discussion here. Need to make a decision: Upgrade the systemd and udev version to 208-6 or sit on the 204-14. This is working fine it seems, and bugs against the 208 are piling up. Nothing however that blares: your system is now unbootable, but that is what I fear. Somehow, on the old system (I had on the previous 32-bit Sid), I never had such fears when upgrading such packages. BTW, before scrapping that installation due to a bad HD, I installed the || dependency to keep the old init because I did not know anything about the changeover. Seems I got it with the new 64bit installation, wheezy upgraded to Sid. What I always do when I'm worried about a new version, which I always am, is to install it on an experimental machine first. Put it on a dumpster king you've had since 2006, and see what it does. Because really, everything bad I said about systemd was a philosophical thing: I have no idea how well it does or doesn't run your computer under normal circumstances. I did a fresh install of Jessie. Nary a problem since. The only dot directories I carried over were ./mozilla and ./thunderbird. Since Jessie is a quantum leap from Wheezy I would leave the rest of the dot files and directories creations to the Big Brains, who know better than the average knuckle-dragging user, like me. Ric -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e298fb.3010...@gmail.com
Re: End of hypocrisy, beginning of reason
On 08/06/2014 09:05 AM, Steve Litt wrote: Screw that! I'm buying an old Kaypro 2x on Ebay, and using CPM for the rest of my life! I have fond memories of my old Kaypro, the Televideos ( had them all, including the portable and the server), IMSAI and Altos computers and CP/M. And even MP/M. I think Linux is what a 64 bit MP/M would be. :) Ric -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e29294.4040...@gmail.com
Re: End of hypocrisy, beginning of reason
On 08/06/2014 09:05 AM, Steve Litt wrote: On Tue, 5 Aug 2014 16:51:03 -0400 Tom H wrote: On Tue, Aug 5, 2014 at 3:44 PM, Steve Litt wrote: LOL, perhaps I'll boot to bin/bash, and then run a script to do everything else. Oh wait, I can't do that: I hear PAM now depends on systemd, for what reason I haven't a clue. Maybe you should look into adapting the Android Init Language :) Screw that! I'm buying an old Kaypro 2x on Ebay, and using CPM for the rest of my life! :-) SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance Good luck finding floppies! --doug -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e29271.80...@optonline.net
Re: End of hypocrisy ?
On Wed, 6 Aug 2014 16:25:21 -0400 Tom H wrote: > So, yeah, /var/log/messages sucks, and journalctl is better at > generating a compatible output that that file ever was in itself. I definitely agree. --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806162719.f58fb0d671418b3495a7d...@1024bits.com
Re: End of hypocrisy ?
On Wed, 6 Aug 2014 22:15:08 +0300 Andrei POPESCU wrote: > The advantage of journald is that it captures more information because > it runs much earlier and also because it captures stdin (?!) and stderr > of daemons. The data has more metadata and is also better structured and > indexed (hence the need for binary storage). I've seen this... However, I would prefer to take it several steps farther, and store the log data in a database; postgresql, of course, is there any other? ... Think of this powerful use case: given a server farm of 1000 or so hosts. Each server has a write only ssl connection to an external postgresql database for log purposes. Of course copies of the logs can be kept locally, but think of the security increase of not storing apache, mail, or even auth logs locally. And think of the standardization that would come almost by default. With a few well chosen queries, and a little R magic, the entire 1000 host server farm could be evaluated quickly in a report style that even management might understand... /sarc Perhaps this functionality is already built into systemd... and we'd never know until we look through the header files in the source code, and discover that - Yes! - journalctl REMOTE_LOGGING=2.5 means activate the secure remote pgsql capability... /sarc --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806162620.5ec7f9a56cfaf26f4c30f...@1024bits.com
Re: End of hypocrisy ?
On Wed, Aug 6, 2014 at 5:54 AM, Slavko wrote: > Dňa Tue, 5 Aug 2014 16:33:23 -0400 Tom H napísal: >> On Tue, Aug 5, 2014 at 9:50 AM, Slavko wrote: >>> Dňa Tue, 5 Aug 2014 08:58:47 -0400 Tom H >>> napísal: If tomh-init is faster than htom-init, whether there's just ssh running or 100 daemons running, I want to use tomh-init. I can understand that there are people who don't want to adopt systemd simply because it boots faster because they dislike some other aspect(s) of systemd, but attacking systemd because it boots faster is silly. >>> >>> I know, that you are not responding to me, but i have one note: >>> >>> The boot speed is often used as argument for the systemd. But no all >>> users are interested on boot time, then there are reaction as this >>> (and as my). IMO, there aren't a lot information about other >>> aspects of systemd and then people (include me) don't know about >>> them. >>> >>> Until will be boot time again and again used as argument, then here >>> will be responses as these. >>> >>> To be precise, i often read about these things: monolitic, binary >>> files and boot speed. I don't like first two and i am not >>> interested in latest. >> >> I thought that I'd answered you. >> >> I'm objecting to this line of reasoning: I'm not interested in boot >> speed therefore I'm not interested in systemd. >> >> Since you're not interested in boot speed, you shouldn't care that >> boot's faster with systemd! You don't have to dislike everything that >> systemd claims that it provides. >> >> But if you want to say "boot speed isn't enough of an argument for me >> to like/use systemd", fine. > > Yes, that is what i mean, thanks for help - writing my thinks in > English is sometime terrible for me. You're welcome. I'm glad that we cleared this up. > Yes, you have rsyslog for storing logs in text files. Now you have two > deamons for one thing. Nice, but where is the advantage? > > I understand that sometime there is time to change, e.g. from text to > binary files, it is OK. But to i (and perhaps others too) can accept > this change, it must give something, what is useful for me. Imagine if the systemd maintainers proposed to replace rsyslog with journald. I'd unsubscribe for a month or two in order to let the outrage die down. :) At my $day_job, as part of our future RHEL 7 rollout, we're looking into using journald for local logs and configuring rsyslog to send our logs to a dedicated syslog server without storing any of the usual "/var/log/" files locally. This is from an email by Lennart: /var/log/messages is *very* badly designed: The timestamps do not contain a year The timestamps do not contain a timezone The timestamps are accurate to the second only PID information is optional, not implied PID information is fakeable, because user supplied The file "tag" part is completely optional, free-form, and fakeable by unpriveed clients The files do not carry any information about the log priority The files do not carry any information about who is logging (service, process name, argv, binary path..) The files do not carry any information about the credentials of who is logging (uid, gid, selinux context, audit, ...) And so on and so on. It's so bad, that rsyslog upstream even suggests not to use these files anymore, but write them in a more modern formatting that leaves a bit more information in (such as iso timestamps). But you know what? If you do that than all your compatibility is gone too. The interesting things is that "journalctl" is *better* at generating the same text stream that is normally contained in /var/log/messages than /var/log/messages itself is. "journalctl" can stuff more information into it then /var/log/messages. And how does that happen? Because we have more data around. We can agument the ouput with colors (indicating priorities), we can add additional informational separator lines (indicating reboots), we can add add in fields that aren't there (such as the tag from the comm field, or the PID). We can timezone correct the timestamps (because we have UTC times). And we can filter by any of the fields, securely. So, yeah, /var/log/messages sucks, and journalctl is better at generating a compatible output that that file ever was in itself. I didn't save the URL :( And another: > So maybe we (Fedora) should go with XML instead of binary or some > dedicated RDMBS for storing system logs? I'm not against binary log > format but try to understand why it's superior to text and also why > something more sophisticated isn't used if we really need this > additional meta data that could not be included in plain text? XML and text files are not sanely indexable. Real database are large packages that we cannot pull into minimal systems. Beyond that, and that's most important: the specific requirements are different from what those systems provide. We want something minimal, C-based, that can work without any service
Re: End of hypocrisy ?
On Mi, 06 aug 14, 11:54:17, Slavko wrote: > > Yes, you have rsyslog for storing logs in text files. Now you have two > deamons for one thing. Nice, but where is the advantage? rsyslog is only needed if you want text logs. You could remove it and configure journald to store its own (binary). > I understand that sometime there is time to change, e.g. from text to > binary files, it is OK. But to i (and perhaps others too) can accept > this change, it must give something, what is useful for me. > > Then what are advantages of the systemd? I see only disadvantages... The advantage of journald is that it captures more information because it runs much earlier and also because it captures stdin (?!) and stderr of daemons. The data has more metadata and is also better structured and indexed (hence the need for binary storage). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: End of hypocrisy ? (Alt. title: Learning to cope with systemd)
On Wed 06 Aug 2014 at 12:02:45 -0400, John wrote: > On 05/08/14, Brian (a...@cityscape.co.uk) wrote: > > > >... and then I > > > noticed /etc/cups/cupsd-systemd-listen.conf. I _guess_ it was > > > installed behind my back without any warning. ... > > It is impossible on Debian for a file to be installed behind one's > > back. Of course, if you not look at what a package contains, > > README.Debian, a changelog, NEWS.Debian etc then it may look like > > that. > > Does anyone read all that as a matter of routine upgrading? I ran > aft-file search on the file, to see what package was involved, and got > no return, which makes it hard to figure out which changelog, etc. to > read. Many don't. But while they could correctly claim everything was done without their knowledge they cannot maintain it was done behind their backs. apt-file (or dpkg -S) would find nothing because the file is generated by the preinst of cups-daemon. > > I would say it is extremely unlikely that > > cupsd-systemd-listen.conf broke your cups. > > My reason for suspecting cupsd-systemd-listen.conf is that I did not > configure it (not knowing it was there), so it did not list anything. > I had no localhost:631, no cups socket -- because I had nothing listed > in that file? Among the changes I made in getting my printer going > again was adding > ListenStream=127.0.0.1:631 > ListenStream=localhost:631 > ListenStream=/var/run/cups/cups.sock > Probably overkill, I admit. > > > But it is in the past, so we can leave it at that. > > Unless, of course, there's a lesson here for someone trying to get > systemd to work. There has been a bug in writing cupsd-systemd-listen.conf but not, as far as I know, one which leaves it completely empty. "ListenStream=/var/run/cups/cups.sock" is taken care of in cups.socket so the line is superfluous. > >> 3. ... Since systemd gives pretty good error messages, life got much > >> easier I got to read them, by amending /etc/inittab by adding > >> --noclear thus: 1:2345:respawn:/sbin/getty > > /etc/inittab is not a file systemd looks at. > > I know. But systemd boot messages, along with those useful hints at > where to find errors, vanish unless --noclear is added. Maybe there's > a journalctl option that includes boot errors, but I haven't found it > yet. > > > You may want to read the thread which contains this post: > > https://lists.debian.org/87bns2roy6@turtle.gmx.de > > Yeah, that's the thread where I learned to set --noclear. I put it in > inittab, even though systemd has its own location, just because the > option works from there. I think you may be misunderstanding something. Systemd puts the "--noclear" in getty@.service and never reads initttab. All it does is clear the screen when a getty is started and a login prompt presented. I cannot see how doing this affects anything shown by journalctrl. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/06082014182224.71246ba02...@desktop.copernicus.demon.co.uk
Re: End of hypocrisy, beginning of reason
On Wed 06 Aug 2014 at 11:03:45 -0400, Jeff Bauer wrote: > On 08/05/2014 07:01 PM, AW wrote: > >And the documentation on the official systemd site is quite terrible, > >at least so far as I've been able to discover. > > They must have copy/pasted the initial systemd documentation from > the Arch Linux Wiki. When the powers that be over at Arch Linux > decided to change over to systemd, the often hostile condescension > shown to end users having problems was truly disturbing, and one key > reason I moved over to Debian. At least two people know which web site is being referred to. Is posting a link possible? > Some of the posts in this thread remind me of what I read during my > last days using Arch, so I can't help but wonder if this relatively > recent adventure into Debianland is going seem like a blink of an > eye compared to the 5+ years with Arch. It must be quite dreadful for you to have endure a repetion of your previous experience. But stick with it; users with technical problems have always found help in -user. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/06082014184650.809eef2bb...@desktop.copernicus.demon.co.uk
Re: End of hypocrisy, beginning of reason
Steve Litt wrote: On Tue, 5 Aug 2014 16:51:03 -0400 Tom H wrote: On Tue, Aug 5, 2014 at 3:44 PM, Steve Litt wrote: LOL, perhaps I'll boot to bin/bash, and then run a script to do everything else. Oh wait, I can't do that: I hear PAM now depends on systemd, for what reason I haven't a clue. Maybe you should look into adapting the Android Init Language :) Screw that! I'm buying an old Kaypro 2x on Ebay, and using CPM for the rest of my life! :-) Plan9! :-) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e259e5.3020...@meetinghouse.net
Re: End of hypocrisy ? (Alt. title: Learning to cope with systemd)
On 05/08/14, Brian (a...@cityscape.co.uk) wrote: > > But I've also been trying to learn to cope with our future via > > init=/bin/systemd. > Irrespective of what future direction you take this open-minded attitude > is commendable. Thanks. > >... and then I > > noticed /etc/cups/cupsd-systemd-listen.conf. I _guess_ it was > > installed behind my back without any warning. ... > It is impossible on Debian for a file to be installed behind one's > back. Of course, if you not look at what a package contains, > README.Debian, a changelog, NEWS.Debian etc then it may look like > that. Does anyone read all that as a matter of routine upgrading? I ran aft-file search on the file, to see what package was involved, and got no return, which makes it hard to figure out which changelog, etc. to read. > I would say it is extremely unlikely that > cupsd-systemd-listen.conf broke your cups. My reason for suspecting cupsd-systemd-listen.conf is that I did not configure it (not knowing it was there), so it did not list anything. I had no localhost:631, no cups socket -- because I had nothing listed in that file? Among the changes I made in getting my printer going again was adding ListenStream=127.0.0.1:631 ListenStream=localhost:631 ListenStream=/var/run/cups/cups.sock Probably overkill, I admit. > But it is in the past, so we can leave it at that. Unless, of course, there's a lesson here for someone trying to get systemd to work. >> 3. ... Since systemd gives pretty good error messages, life got much >> easier I got to read them, by amending /etc/inittab by adding >> --noclear thus: 1:2345:respawn:/sbin/getty > /etc/inittab is not a file systemd looks at. I know. But systemd boot messages, along with those useful hints at where to find errors, vanish unless --noclear is added. Maybe there's a journalctl option that includes boot errors, but I haven't found it yet. > You may want to read the thread which contains this post: > https://lists.debian.org/87bns2roy6@turtle.gmx.de Yeah, that's the thread where I learned to set --noclear. I put it in inittab, even though systemd has its own location, just because the option works from there. > I look forward to your help. And I to yours. -- johnrchamp...@wowway.com GPG key 1024D/99421A63 2005-01-05 EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63 gpg --keyserver subkeys.pgp.net --recv-keys 99421A63 signature.asc Description: Digital signature
Re: End of hypocrisy, beginning of reason
On 08/05/2014 07:01 PM, AW wrote: And the documentation on the official systemd site is quite terrible, at least so far as I've been able to discover. They must have copy/pasted the initial systemd documentation from the Arch Linux Wiki. When the powers that be over at Arch Linux decided to change over to systemd, the often hostile condescension shown to end users having problems was truly disturbing, and one key reason I moved over to Debian. Some of the posts in this thread remind me of what I read during my last days using Arch, so I can't help but wonder if this relatively recent adventure into Debianland is going seem like a blink of an eye compared to the 5+ years with Arch. Jeff -- hangout: ##b0rked on irc.freenode.net diversion: http://alienjeff.net - visit The Fringe quote: "The foundation of authority is based upon the consent of the people." - Thomas Hooker -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e243d1.2050...@charter.net
Re: End of hypocrisy ?
On Thu, 7 Aug 2014 01:46:14 +1200 Chris Bannister wrote: > On Tue, Aug 05, 2014 at 09:38:24AM -0400, Steve Litt wrote: > > > > This is where we differ. I'd rather have building blocks from which > > I could build anything, rather than a monolith I need to trick into > > doing what I want it to do. > > Oh, so you don't run a DE then. I do. At varying times, I run Openbox, dwm, LXDE or Xfce. > > In that case I suggest either NetBSD http://www.netbsd.org/ or maybe > Linux From Scratch http://www.linuxfromscratch.org/ LOL, if I consider Arch's 40 manual step installation too error prone, can you imagine me doing Linux From Scratch? But NetBSD, h. FreeBSD is wonderful, and I would have switched to it a long time ago, but they keep changing their package manager and making it worse, and Ports starts conflicting with their Package Manager of the Month, and what a mess! PC-BSD is just a pretty face pasted onto FreeBSD, not good enough. OpenBSD would be exactly what I want, but I've had some video resolution problems with it, and I'm concerned that a lot of apps haven't been ported to it. It never occurred to me to try NetBSD, but I really should, so I will. Thanks for the tip. > > I suppose it all depends on the size of the building blocks you are > after. > They vary. Generally speaking, I like bigger building blocks for GUI, and smaller ones for data processing. I'm never going to make my own window manager. I studied the code for one of the smallest ones, dwm, and it's very detailed. I wasn't even able to figure out how to add a function to list all GUI windows grouped by tagset (dwm equivalent of workspaces). Lack of that function was the main reason I switched back to Openbox. Thanks for the tip on NetBSD. I'll try it. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806101934.335d5...@mydesq2.domain.cxm
Re: End of hypocrisy ?
On Tue, Aug 05, 2014 at 09:38:24AM -0400, Steve Litt wrote: > > This is where we differ. I'd rather have building blocks from which I > could build anything, rather than a monolith I need to trick into doing > what I want it to do. Oh, so you don't run a DE then. In that case I suggest either NetBSD http://www.netbsd.org/ or maybe Linux From Scratch http://www.linuxfromscratch.org/ I suppose it all depends on the size of the building blocks you are after. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806134614.GD20458@tal
Re: End of hypocrisy, beginning of reason
On Tue, 5 Aug 2014 16:51:03 -0400 Tom H wrote: > On Tue, Aug 5, 2014 at 3:44 PM, Steve Litt > wrote: > > > > LOL, perhaps I'll boot to bin/bash, and then run a script to do > > everything else. Oh wait, I can't do that: I hear PAM now depends on > > systemd, for what reason I haven't a clue. > > Maybe you should look into adapting the Android Init Language :) Screw that! I'm buying an old Kaypro 2x on Ebay, and using CPM for the rest of my life! :-) SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806090550.7c990...@mydesq2.domain.cxm
Re: End of hypocrisy ?
On Tue, 05 Aug 2014 23:43:09 +0300 David Baron wrote: > An amazing amount of discussion here. > > Need to make a decision: Upgrade the systemd and udev version to > 208-6 or sit on the 204-14. This is working fine it seems, and bugs > against the 208 are piling up. Nothing however that blares: your > system is now unbootable, but that is what I fear. > > Somehow, on the old system (I had on the previous 32-bit Sid), I > never had such fears when upgrading such packages. BTW, before > scrapping that installation due to a bad HD, I installed the || > dependency to keep the old init because I did not know anything about > the changeover. Seems I got it with the new 64bit installation, > wheezy upgraded to Sid. What I always do when I'm worried about a new version, which I always am, is to install it on an experimental machine first. Put it on a dumpster king you've had since 2006, and see what it does. Because really, everything bad I said about systemd was a philosophical thing: I have no idea how well it does or doesn't run your computer under normal circumstances. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806090343.1f961...@mydesq2.domain.cxm
Re: End of hypocrisy ?
Ahoj, By my mistake i post it directly to Dan - i am sorry! I repost it to list again... Dňa Tue, 5 Aug 2014 12:07:41 -0700 Don Armstrong napísal: > On Tue, 05 Aug 2014, Slavko wrote: > > When i read first time about change default of the init, i believe > > (or hope?), that there will be choice. And don't matter if this > > choice will be at install time, or after install... I wrote to this > > list too, that this is *only* default. But now i read more and more > > about problems, dependencies from user space and this sounds bad > > for me. And i start to afraid. > > Choice is expensive. Debian doesn't have unlimited developer time. If > a choice that you would want to be able to make isn't currently > available, then your only real alternative is to do the work (or > otherwise cause the work to be done.) IMO most interesting part of whole thread. It seems, that the thread's subject is true. The systemd is not the default choice, it will be only one choice! Is this for what you vote (and others) as member of CTTE? regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: End of hypocrisy ?
Ahoj, Dňa Tue, 5 Aug 2014 16:33:23 -0400 Tom H napísal: > On Tue, Aug 5, 2014 at 9:50 AM, Slavko wrote: > > Dňa Tue, 5 Aug 2014 08:58:47 -0400 Tom H > > napísal: > >> > >> If tomh-init is faster than htom-init, whether there's just ssh > >> running or 100 daemons running, I want to use tomh-init. > >> > >> I can understand that there are people who don't want to adopt > >> systemd simply because it boots faster because they dislike some > >> other aspect(s) of systemd, but attacking systemd because it boots > >> faster is silly. > > > > I know, that you are not responding to me, but i have one note: > > > > The boot speed is often used as argument for the systemd. But no all > > users are interested on boot time, then there are reaction as this > > (and as my). IMO, there aren't a lot information about other > > aspects of systemd and then people (include me) don't know about > > them. > > > > Until will be boot time again and again used as argument, then here > > will be responses as these. > > > > To be precise, i often read about these things: monolitic, binary > > files and boot speed. I don't like first two and i am not > > interested in latest. > > I thought that I'd answered you. > > I'm objecting to this line of reasoning: I'm not interested in boot > speed therefore I'm not interested in systemd. > > Since you're not interested in boot speed, you shouldn't care that > boot's faster with systemd! You don't have to dislike everything that > systemd claims that it provides. > > But if you want to say "boot speed isn't enough of an argument for me > to like/use systemd", fine. Yes, that is what i mean, thanks for help - writing my thinks in English is sometime terrible for me. > Re "binary files": Please repeat after me "systemd doesn't require > binary files." I currently have two systemd systems, a sid VM (where > systemd-sysv has been pulled in by the recent libpam-systemd > dependency change) and a Fedora 20 installation on my laptop. On the > sid VM, I have the default Debian setup whereby journald forwards logs > to rsyslog and the logs are stored in text files in "/var/log/". On my > Fedora installation, I've set "Storage=persistent" in > "/etc/systemd/journald.conf" so my only logs are binary files in > "/var/log/journal/". > > Re "monolithic": Someone said earlier in the thread "gratuitous > interdependency". That's more accurate. There are many executables in > systemd and many are interdependent. A systemd fan would tell you that > the interdependency isn't gratuitous; I'd tend to disagree. The interdependency is better describing it - thanks again, but from my point of view, if some parts are not able to work one without other, it is a monolithic block, only splitted to more processes. I am not able to decide (or rate) if this is gratuitous or not, i only see, that there are more things together. Yes, you have rsyslog for storing logs in text files. Now you have two deamons for one thing. Nice, but where is the advantage? I understand that sometime there is time to change, e.g. from text to binary files, it is OK. But to i (and perhaps others too) can accept this change, it must give something, what is useful for me. Then what are advantages of the systemd? I see only disadvantages... -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: End of hypocrisy, beginning of reason
On Wed 06 Aug 2014 at 00:20:56 -0700, Rusi Mody wrote:
> I have a basic question: I want to migrate to systemd [reasons below]
[Snip]
> However aptitude dist-upgrade shows me:
>
> The following packages will be REMOVED:
> graphviz{a} rsyslog{a} sysvinit-core{a}
The testing distribution is in a state of flux so it is not unknown for
a dist-upgrade to want to remove a package from time to time. You would
be allowed a little worry if it happened when testing became Jessie.
> And a 1/2 GB worth of packages to be upgraded including systemd
>
> So I am a bit jittery about going ahead -- removing sysvinit-core seems a
> hard step to reverse :-)
sysvinit-core is already on your system so you are upgrading from
testing to testing. The init package at the present time has a
Pre-depends: of
sysvinit-core | systemd-sysv | upstart ,
which is satisfied on your machine. If you keep sysvinit-core installed
your choice of init system will never be overridden by the init package.
On your system you also appear to have chosen to have libpam-systemd
installed. At the present time it is likely to require systemd-sysv, so
sysvinit-core will be removed. Reversing this removal is as simple as
purging libpam-systemd.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140806095025.gt19...@copernicus.demon.co.uk
Re: End of hypocrisy, beginning of reason
On Wed, 6 Aug 2014 00:20:56 -0700 (PDT)
Rusi Mody wrote:
>
> I have a basic question: I want to migrate to systemd [reasons below]
>
> However...
>
> 1. I see on this list itself evidence of breakage
No doubt about that.
>
> 2. Ive experienced some myself and I could only guess that it was a
> systemd issue until it was pointed out by Michael that it is probably
> a mismatch between sysv and systemd. However given that people are
> getting totally unbootable systems, I's just being a bit careful.
One good reason is having a mount in your /etc/fstab for a removable
medium which may not be present, but if present, will be mounted at
boot. That's a no-no under systemd, and will stop the show.
> What I want is a process where something can be tried out (gingerly)
> and reversed or fixed-in-concrete depending on results.
>
> Ive seen some things about trying out by giving systemd at the grub
> line.
Yes. This can be done for one boot only.
>
> Im already seeing systemd in mount:
>
> systemd on /sys/fs/cgroup/systemd type cgroup
> (rw,nosuid,nodev,noexec,relatime,name=systemd)
>
> However aptitude dist-upgrade shows me:
>
> The following packages will be REMOVED:
> graphviz{a} rsyslog{a} sysvinit-core{a}
>
> And a 1/2 GB worth of packages to be upgraded including systemd
>
> So I am a bit jittery about going ahead -- removing sysvinit-core
> seems a hard step to reverse :-)
No. You can still boot on sysv without sysvinit-core (!). After the
removal of sysvinit-core, you still have to make the deliberate change
to systemd booting.
>
> >From a more theoretical/computer science pov:
> Why I (for whatever its worth) think systemd is (could be) a good
> idea:
>
> Declarative is invariably better than imperative though it can be
> hard to get right at first. And systemd tries to be more
> declarative than sysv.
>
> Whether it succeeds is a different question ;-)
>
> How to make it succeed (with minimal pain) is what I am asking...
>
>
I have a sid with 4000+ packages booting on systemd, and the journal is
quite messy. Having built a copy of it using --get-selections and
--set-selections (and *that's* not as easy as it used to be) I get a
cleaner log, so it seems to be the case that an installation using
systemd from the start (minimal wheezy, upgrade to sid, upgrade sid to
systemd, then pour in the rest of the system) is a bit more stable than
one which is switched over. I also took the opportunity to merge /usr
into /, and I've no idea whether this has improved anything.
But apart from incomprehensible warnings in the log, some of which also
occur in the new system, there isn't much change in behaviour. I had
hoped to be rid of an occasional kernel panic during shutdown, but this
still seems to be present. I'm not aware of anything not working, but I
very rarely print anything from this system, and there are a lot of
cups and colord messages in the log.
--
Joe
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140806090734.5c6f5...@jresid.jretrading.com
Re: End of hypocrisy, beginning of reason
On Wed, Aug 6, 2014 at 2:53 AM, Erwan David wrote:
> On Wed, Aug 06, 2014 at 01:01:57AM CEST, AW
> said:
>> On Tue, 5 Aug 2014 17:57:02 -0400
>> Tom H wrote:
>>>
>>> journalctl SYSLOG_FACILITY=4
>>
>> Thanks!
>> But why '4'? Why not '42'? Or even better...
>> journalctl show auth
>> journalctl show apache2
>> journalctl show postgresql
>> or even better still
>> journalctl show -v postgresql
>
> man says it is journalctl [OPTIONS] [MATCHES] what MATCHES are is not
> defined.
>
> just examples where we have to guess there are "fields" (list not given) two
> of them can be _SYSTEMD_UNIT and _PID
>
> Reading this I feel I am told "this is not for you, you are only a suer and
> you are not allowed to know"
You have to read more than the first lines of a man page to learn how
to use a command.
"man ps" has "ps [options]" and "man nmap" has "nmap [Scan Type...]
[Options] {target specification}"...
See the last lines of my earlier email to display the fields with tab
completion:
https://lists.debian.org/debian-user/2014/08/msg00342.html
Also:
man journalctl
man systemd.journal-fields
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAOdo=syhuanqcgyunzv7huobur7htuc3pqj2ocsw_4bvqu7...@mail.gmail.com
Re: End of hypocrisy, beginning of reason
On Tuesday, August 5, 2014 10:10:02 PM UTC+5:30, Steve Litt wrote:
> On Tue, 5 Aug 2014 09:17:15 -0700
> Don Armstrong wrote:
> > On Tue, 05 Aug 2014, Slavko wrote:
> > > To be precise, i often read about these things: monolitic, binary
> > > files and boot speed. I don't like first two and i am not interested
> > > in latest.
> > These are just accessible reasons. The main reason that I personally
> > voted for systemd over sysv is because systemd (and upstart) provide
> > correct boot sequencing in complex boot situations.
> > For example, if you're using iscsi, and need to start a daemon after
> > the network is up, iscsi is connected, lvm has resynced, and the
> > appropriate filesystems are mounted, this is trivial using systemd or
> > upstart, but very difficult using sysv.[1]
> > The other reason is we also get rid of thousands of lines of
> > difficult-to-maintain boilerplate in init scripts.
> > While sysv may be easier to debug in simple systems, there's a reason
> > why none of the CTTE members (myself included) voted for it.
> > 1: Not impossible, but you basically end up replicating a dependency
> > boot system in shell, and necessarily introduce brittleness and
> > delays.
> Cool! Finally someone who knows it and is on the ground floor. I have
> some questions...
>
> What other tips would you have for those of us who want to, to the
> extent possible, keep systemd as nothing more than the first program to
> be booted, and want to reduce as much as possible what other programs
> need to know about systemd and what systemd needs to know about the
> programs I run?
I have a basic question: I want to migrate to systemd [reasons below]
However...
1. I see on this list itself evidence of breakage
2. Ive experienced some myself and I could only guess that it was a
systemd issue until it was pointed out by Michael that it is probably
a mismatch between sysv and systemd. However given that people are
getting totally unbootable systems, I's just being a bit careful.
What I want is a process where something can be tried out (gingerly)
and reversed or fixed-in-concrete depending on results.
Ive seen some things about trying out by giving systemd at the grub line.
Im already seeing systemd in mount:
systemd on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,name=systemd)
However aptitude dist-upgrade shows me:
The following packages will be REMOVED:
graphviz{a} rsyslog{a} sysvinit-core{a}
And a 1/2 GB worth of packages to be upgraded including systemd
So I am a bit jittery about going ahead -- removing sysvinit-core seems a hard
step to reverse :-)
>From a more theoretical/computer science pov:
Why I (for whatever its worth) think systemd is (could be) a good idea:
Declarative is invariably better than imperative though it can be hard to
get right at first. And systemd tries to be more
declarative than sysv.
Whether it succeeds is a different question ;-)
How to make it succeed (with minimal pain) is what I am asking...
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1d9aed76-a71d-4e1a-b2b3-e53b0779d...@googlegroups.com
Re: End of hypocrisy, beginning of reason
On Tue, Aug 5, 2014 at 7:01 PM, AW wrote: > On Tue, 5 Aug 2014 17:57:02 -0400 > Tom H wrote: >> >> journalctl SYSLOG_FACILITY=4 > > Thanks! > But why '4'? Why not '42'? Or even better... > journalctl show auth > journalctl show apache2 > journalctl show postgresql > or even better still > journalctl show -v postgresql You're welcome. Weirdly, you can find the correspondence between the facility name and the facility number in "/usr/include/x86_64-linux-gnu/sys/syslog.h" and not in a man page. (You can also find it in the IETF syslog RFC!) The ones that I keep in mind are 3 (daemons), 4 (auth), 10 (authpriv). I can't remember any other, although I /think/ that mail is 2. Run "journalctl -u " (u for unit) to see the log for a specific service. "journalctl -u " is the same as (or perhaps I should say "short for") "journalctl _SYSTEMD_UNIT=.service". I don't know why you have to append ".service" to the latter but tab completion takes care of it anyway. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=Sww=tno09cvek9wavlze+rpqgtyvim+yh0znewrfvf...@mail.gmail.com
Re: End of hypocrisy, beginning of reason
On Wed, Aug 06, 2014 at 01:01:57AM CEST, AW said: > On Tue, 5 Aug 2014 17:57:02 -0400 > Tom H wrote: > > > journalctl SYSLOG_FACILITY=4 > > Thanks! > But why '4'? Why not '42'? Or even better... > journalctl show auth > journalctl show apache2 > journalctl show postgresql > or even better still > journalctl show -v postgresql man says it is journalctl [OPTIONS] [MATCHES] what MATCHES are is not defined. just examples where we have to guess there are "fields" (list not given) two of them can be _SYSTEMD_UNIT and _PID Reading this I feel I am told "this is not for you, you are only a suer and you are not allowed to know" -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806065324.gk7...@rail.eu.org
Re: End of hypocrisy, beginning of reason
On Tue, 5 Aug 2014 19:01:57 -0400 AW wrote: > But why '4'? Why not '42'? Or even better... This makes the number '4' meaningful... ... SyslogFacility= Sets the syslog facility to use when logging to syslog. One of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, authpriv, ftp, local0, local1, local2, local3, local4, local5, local6 or local7. See syslog(3) for details. This option is only useful when StandardOutput= or StandardError= are set to syslog. Defaults to daemon. ... Found here: http://www.freedesktop.org/software/systemd/man/systemd.exec.html If I count from zero... 0 = kernel 1 = user 2 = mail 3 = daemon 4 = auth So it would seem that SYSLOG_FACILITY=4 is setting the variable [thus the capitals] to look only at those messages that correspond to auth... This is entirely unintuitive... and inconsistent with the operation of sending messages to the log through syslog... http://man7.org/linux/man-pages/man3/syslog.3.html Here, you would use the much more intuitive variable setting of LOG_AUTH Now, that makes sense --- why the incongruity in settings between sending to the log and retrieving from the log? Anyway -- I'll stop posting my musings, thoughts, and findings -- I'm sure I'm running late on this subject in comparison to many people here... --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014080523.280e30895407a946f573b...@1024bits.com
Re: End of hypocrisy, beginning of reason
On Tue, 5 Aug 2014 17:57:02 -0400 Tom H wrote: > journalctl SYSLOG_FACILITY=4 Thanks! But why '4'? Why not '42'? Or even better... journalctl show auth journalctl show apache2 journalctl show postgresql or even better still journalctl show -v postgresql and I found the '-o verbose' option to output lots of detail per entry. However, I can see that this is going to take awhile to sink into my steel sieve like mind... BTW... I tried SYSLOG_FACILITY=0 [through] 10 I tried SYSLOG_FACILITY=kadhfkjdahfkldhasdflkdasjf and got the first line of the log. I tried syslog_facility=4 [this doesn't work -- apparently the option is case sensitive and in the reverse case of most other command line options. The thing looks really cool with lots of toys. However, there's just no way to figure out how it works without already knowing how it works. And the documentation on the official systemd site is quite terrible, at least so far as I've been able to discover. --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805190157.14f6338181508b927c115...@1024bits.com
Re: End of hypocrisy ? (Alt. title: Learning to cope with systemd)
On Tue 05 Aug 2014 at 14:40:01 -0400, John wrote: [Some snipping] > But I've also been trying to learn to cope with our future via > init=/bin/systemd. Irrespective of what future direction you take this open-minded attitude is commendable. > 2. I _think_ systemd broke my ability to print, or even to ping > localhost. Three days of thrashing around with cups, hplip, including > several reinstalls of both, and resetting locales went by, and then I > noticed /etc/cups/cupsd-systemd-listen.conf. I _guess_ it was > installed behind my back without any warning. Two more days of > thrashing around and the printer works again. But I made so many > changes that I am not at all sure which of them finally fixed the > problem. Again, details available on request. It is impossible on Debian for a file to be installed behind one's back. Of course, if you not look at what a package contains, README.Debian, a changelog, NEWS.Debian etc then it may look like that. I would say it is extremely unlikely that cupsd-systemd-listen.conf broke your cups. But it is in the past, so we can leave it at that. > 3. Learning to use journalctl and systemctl takes time. Since systemd > gives pretty good error messages, life got much easier I got to read > them, by amending /etc/inittab by adding --noclear thus: > 1:2345:respawn:/sbin/getty --noclear 38400 tty1 /etc/inittab is not a file systemd looks at. You may want to read the thread which contains this post: https://lists.debian.org/87bns2roy6@turtle.gmx.de > I have no doubt I have much more to learn. Maybe some of you do too? > I look forward to your help. I'll join you in learning. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805222613.gs19...@copernicus.demon.co.uk
Re: End of hypocrisy, beginning of reason
On Tue, Aug 5, 2014 at 4:12 PM, AW wrote: > > cat /var/log/auth.log > or > journalctl 'something unknown by me' journalctl SYSLOG_FACILITY=4 There's tab completion, so on my laptop where I've aliased systemctl and journalctl to sc and jc (and duplicated the systemctl and journalctl bash completion), I type: jc[space]S[tab]F[tab]4 To know what fields are available: jc[space]-F[space][tab][tab] or jc[space]-F[tab][tab][tab] -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=Sx0FpLiZpEuHbepOSU=TFoMwM6XLNn7A6nQv=12npp...@mail.gmail.com
Re: End of hypocrisy, beginning of reason
On Tue, Aug 5, 2014 at 3:44 PM, Steve Litt wrote: > > LOL, perhaps I'll boot to bin/bash, and then run a script to do > everything else. Oh wait, I can't do that: I hear PAM now depends on > systemd, for what reason I haven't a clue. Maybe you should look into adapting the Android Init Language :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=Szh3zrTpOEC4vboUq7zGmJwJq6=ahhwk2laublfo19...@mail.gmail.com
Re: End of hypocrisy ?
An amazing amount of discussion here. Need to make a decision: Upgrade the systemd and udev version to 208-6 or sit on the 204-14. This is working fine it seems, and bugs against the 208 are piling up. Nothing however that blares: your system is now unbootable, but that is what I fear. Somehow, on the old system (I had on the previous 32-bit Sid), I never had such fears when upgrading such packages. BTW, before scrapping that installation due to a bad HD, I installed the || dependency to keep the old init because I did not know anything about the changeover. Seems I got it with the new 64bit installation, wheezy upgraded to Sid. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8255055.sd1RXOVEXc@dovidhalevi
Re: End of hypocrisy ?
On Tue, Aug 5, 2014 at 9:50 AM, Slavko wrote: > Dňa Tue, 5 Aug 2014 08:58:47 -0400 Tom H napísal: >> >> If tomh-init is faster than htom-init, whether there's just ssh >> running or 100 daemons running, I want to use tomh-init. >> >> I can understand that there are people who don't want to adopt systemd >> simply because it boots faster because they dislike some other >> aspect(s) of systemd, but attacking systemd because it boots faster is >> silly. > > I know, that you are not responding to me, but i have one note: > > The boot speed is often used as argument for the systemd. But no all > users are interested on boot time, then there are reaction as this (and > as my). IMO, there aren't a lot information about other aspects of > systemd and then people (include me) don't know about them. > > Until will be boot time again and again used as argument, then here > will be responses as these. > > To be precise, i often read about these things: monolitic, binary files > and boot speed. I don't like first two and i am not interested in > latest. I thought that I'd answered you. I'm objecting to this line of reasoning: I'm not interested in boot speed therefore I'm not interested in systemd. Since you're not interested in boot speed, you shouldn't care that boot's faster with systemd! You don't have to dislike everything that systemd claims that it provides. But if you want to say "boot speed isn't enough of an argument for me to like/use systemd", fine. Re "binary files": Please repeat after me "systemd doesn't require binary files." I currently have two systemd systems, a sid VM (where systemd-sysv has been pulled in by the recent libpam-systemd dependency change) and a Fedora 20 installation on my laptop. On the sid VM, I have the default Debian setup whereby journald forwards logs to rsyslog and the logs are stored in text files in "/var/log/". On my Fedora installation, I've set "Storage=persistent" in "/etc/systemd/journald.conf" so my only logs are binary files in "/var/log/journal/". Re "monolithic": Someone said earlier in the thread "gratuitous interdependency". That's more accurate. There are many executables in systemd and many are interdependent. A systemd fan would tell you that the interdependency isn't gratuitous; I'd tend to disagree. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=SwH=pgcapr0qbhmsba9wmlnbaxk-6mev61we_b_zzj...@mail.gmail.com
Re: End of hypocrisy, beginning of reason
On Tue, 5 Aug 2014 15:44:50 -0400 Steve Litt wrote: >I hear PAM now depends on >systemd, for what reason I haven't a clue. I'd bet last Tuesday's burrito special that you could compile and install a version of PAM without systemd... However, it's not all surprising that PAM pulls in a systemd dependency. All those services and log files need to be operated using appropriate users. cat /var/log/auth.log or journalctl 'something unknown by me' I will readily admit that the first command seems much more logical to me than the second... but unfamiliarity does not equate to 'bad'. --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805161240.0ffb9c478e2f6b12d952c...@1024bits.com
Re: End of hypocrisy, beginning of reason
On Tue, 5 Aug 2014 13:05:59 -0400 AW wrote: > On Tue, 5 Aug 2014 12:32:48 -0400 > Steve Litt wrote: > > >When I switch to systemd, I'd like to have it as isolated as humanly > >possible, just because I'm a modularity kind of guy. > > I've been watching the thread here... and I understand the thought of > not changing from sysvinit because sysvinit works well [sometimes] ... > > But here you've made a point that should lead you directly to use > systemd over sysvinit... especially Debian styled sysvinit. [clip section about how systemd works] > I understand the desire of"K.I.S.S.", but the reality is that sysvinit > is already massively complex and for all intents and purposes > is monolithic in nature. I'm a big fan of KISS, but in this case I'm speaking not of KISS but of modularity and encapsulation. The less entangled things are, the more clean test points you have to measure, the more places you can insert your own little program to do something, and the less dependencies in your package manager or when ./configure;make;make install. It's possible to do modular badly, or even complexly, and perhaps that's what sysvinit has done. That doesn't mean entanglement is better: It means you need to fix your modular system. LOL, perhaps I'll boot to bin/bash, and then run a script to do everything else. Oh wait, I can't do that: I hear PAM now depends on systemd, for what reason I haven't a clue. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805154450.64713...@mydesq2.domain.cxm
Re: End of hypocrisy, beginning of reason
On Tue 05 Aug 2014 at 12:32:48 -0400, Steve Litt wrote: > Cool! Finally someone who knows it and is on the ground floor. I have > some questions... Debian isn't a department store. But if it were you want the penthouse, which is where the the systemd maintainers reside. > When I switch to systemd, I'd like to have it as isolated as humanly > possible, just because I'm a modularity kind of guy. If you work for Ikea or buy its furniture it's an understandable stance to take. You boot with systemd but want it to take no part in what follows. Have you thought of isolating udev and the kernel in the same way? > I'm thinking of starting the minimum possible daemons with systemd, and > starting the rest with daemontools. Of course, I've never before had to > manage run order in daemontools, so that might be a little challenging, > but I think I can handle it, even if I have to pull off a kludge. Most users don't want kludges. What they want is a free, technically competent system. Over the past 20 years Debian has delivered this time after time. Your are, of course, free to pervert this on your own systems. If you can do the same with daemontools as Debian does with systemd we wish you all good fortune. > Another challenge will be to prevent systemd from starting the daemons > I want to launch with daemontools, even though the package installer > tells systemd to launch those programs. Is it pretty easy to tell > systemd not to launch specific daemons? Someone will point out systemd has documention; inexperienced users have to be pointed directly to it. An exception can be made for you. > I will, as usual when I use Debian, start my desktop environment with > startx or xinit. I usually use Xfce, LXDE, Openbox, dwm or i9. Do you > think I'll have systemd dependencies with those de's started with > startx or xinit? Impossible to answer; you would have to be specific about what you have on your system. For example, is colord installed? > What other tips would you have for those of us who want to, to the > extent possible, keep systemd as nothing more than the first program to > be booted, and want to reduce as much as possible what other programs > need to know about systemd and what systemd needs to know about the > programs I run? Insofar as the question is understandable, you could first consider not using fantasy as a basis or motivating factor for building a modern computer system. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805192603.gr19...@copernicus.demon.co.uk
Re: End of hypocrisy ?
On Tue, 05 Aug 2014, Slavko wrote: > Dňa Tue, 5 Aug 2014 09:17:15 -0700 Don Armstrong > napísal: > > These are just accessible reasons. The main reason that I personally > > voted for systemd over sysv is because systemd (and upstart) provide > > correct boot sequencing in complex boot situations. > > IMO, users deserve reasons, which has value for them itself, > not for others. The reasoning is pretty well laid out in the CTTE decision, the discussion, and the position statements. > When i read first time about change default of the init, i believe (or > hope?), that there will be choice. And don't matter if this choice > will be at install time, or after install... I wrote to this list too, > that this is *only* default. But now i read more and more about > problems, dependencies from user space and this sounds bad for me. And > i start to afraid. Choice is expensive. Debian doesn't have unlimited developer time. If a choice that you would want to be able to make isn't currently available, then your only real alternative is to do the work (or otherwise cause the work to be done.) > I am not able to suspend this machine when boot via systemd. OK It > seems, that it is not a systemd problem - but the difference is simple: > without systemd it works, with it doesn't, then systemd is a problem > for me too. If systemd isn't working properly, please file bugs or comment on the existing bugs to provide more information if there isn't already enough information. > > 1: Not impossible, but you basically end up replicating a dependency > > boot system in shell, and necessarily introduce brittleness and > > delays. > > Delays, delays... And we are back at the boot time, where we start. Delay is a small price to pay; the real problem here is brittleness and deadlock in a delay. -- Don Armstrong http://www.donarmstrong.com Religion is religion, however you wrap it, and like Quell says, a preoccupation with the next world clearly signals an inability to cope credibly with this one. -- Richard K. Morgan "Broken Angels" p65 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805190740.gi2...@rzlab.ucr.edu
Re: End of hypocrisy ? (Alt. title: Learning to cope with systemd)
On 05/08/14, Don Armstrong (d...@debian.org) wrote: > > These are just accessible reasons. The main reason that I personally > voted for systemd over sysv is ... > ...there's a reason > why none of the CTTE members (myself included) voted for it. > ... Thanks to Don for taking the time to write about the issue on debian-user; hearing from a member of CTTE is much appreciated. In May, I wrote to ask for help in keeping systemd out (https://lists.debian.org/debian-user/2014/05/msg00587.html) and got good help from Steve Langasek. Since my query owed a lot to my having lurked on debian-devel, I cc'd the note there. (To teach me manners, the very first response berated me for flame-baiting. (debian-devel/2014/05/msg00359)) Since then, I've had systemd-shim installed and in /etc/apt/preferences, a stanza reading Package: systemd-sysv Pin: origin * Pin-Priority: -100 But I've also been trying to learn to cope with our future via init=/bin/systemd. 1. I had to give up using Eterm, which just races under systemd. It took two days to figure out how to accomplish the same chore using aterm. (Complicated and uninteresting details available on request.) 2. I _think_ systemd broke my ability to print, or even to ping localhost. Three days of thrashing around with cups, hplip, including several reinstalls of both, and resetting locales went by, and then I noticed /etc/cups/cupsd-systemd-listen.conf. I _guess_ it was installed behind my back without any warning. Two more days of thrashing around and the printer works again. But I made so many changes that I am not at all sure which of them finally fixed the problem. Again, details available on request. 3. Learning to use journalctl and systemctl takes time. Since systemd gives pretty good error messages, life got much easier I got to read them, by amending /etc/inittab by adding --noclear thus: 1:2345:respawn:/sbin/getty --noclear 38400 tty1 I have no doubt I have much more to learn. Maybe some of you do too? I look forward to your help. -- johnrchamp...@wowway.com GPG key 1024D/99421A63 2005-01-05 EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63 gpg --keyserver subkeys.pgp.net --recv-keys 99421A63 signature.asc Description: Digital signature
Re: End of hypocrisy ?
Ahoj, Dňa Tue, 5 Aug 2014 09:17:15 -0700 Don Armstrong napísal: > On Tue, 05 Aug 2014, Slavko wrote: > > To be precise, i often read about these things: monolitic, binary > > files and boot speed. I don't like first two and i am not interested > > in latest. > > These are just accessible reasons. The main reason that I personally > voted for systemd over sysv is because systemd (and upstart) provide > correct boot sequencing in complex boot situations. IMO, users deserve reasons, which has value for them itself, not for others. > For example, if you're using iscsi, and need to start a daemon after > the network is up, iscsi is connected, lvm has resynced, and the > appropriate filesystems are mounted, this is trivial using systemd or > upstart, but very difficult using sysv.[1] I never meet these problems, then i cannot to appreciate it. How many people are as i in this? > The other reason is we also get rid of thousands of lines of > difficult-to-maintain boilerplate in init scripts. Yes, i meet some of these scripts, then i can to appreciate it. > > While sysv may be easier to debug in simple systems, there's a reason > why none of the CTTE members (myself included) voted for it. I don't see the problem in the change of the default init system. Your response forced me to small stop and think about defaults in Debian. I do not often use Debian's defaults. I remember as i need to specify boot options to install KDE and not Gnome, but it was no problem. Yes, there was time, when i install Debian without DE, to install the one by my choice latter. I don't use the the d-i tasks for DNS, or web server, because i don't use the defaults (only SSH server from there). My first thing after install Debian is to remove the default installed NFS server - no problem too. etc, etc. All these things are clean, straightforward and are possible after system install. Simple, i see no problem, that my defaults are different, than Debian defaults and i consider this as one of flags of the freedom. When i read first time about change default of the init, i believe (or hope?), that there will be choice. And don't matter if this choice will be at install time, or after install... I wrote to this list too, that this is *only* default. But now i read more and more about problems, dependencies from user space and this sounds bad for me. And i start to afraid. I am not able to suspend this machine when boot via systemd. OK It seems, that it is not a systemd problem - but the difference is simple: without systemd it works, with it doesn't, then systemd is a problem for me too. > 1: Not impossible, but you basically end up replicating a dependency > boot system in shell, and necessarily introduce brittleness and > delays. Delays, delays... And we are back at the boot time, where we start. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: End of hypocrisy, beginning of reason
On Tue, 05 Aug 2014, Steve Litt wrote: > Cool! Finally someone who knows it and is on the ground floor. I have > some questions... > > When I switch to systemd, I'd like to have it as isolated as humanly > possible, just because I'm a modularity kind of guy. > > I'm thinking of starting the minimum possible daemons with systemd, and > starting the rest with daemontools. Of course, I've never before had to > manage run order in daemontools, so that might be a little challenging, > but I think I can handle it, even if I have to pull off a kludge. I'm not sure why you'd also run daemontools in addition to systemd, as systemd also provides most of the daemontools feature set. > Is it pretty easy to tell systemd not to launch specific daemons? systemctl disable foo -t service; or whatever is appropriate. > I will, as usual when I use Debian, start my desktop environment with > startx or xinit. I usually use Xfce, LXDE, Openbox, dwm or i9. Do you > think I'll have systemd dependencies with those de's started with > startx or xinit? That depends on the developers of those DEs. I wouldn't be surprised if they eventually grew dependencies on libpam-systemd because of the difficulties of figuring out who is actually a local user without using that (or a similar interface). > What other tips would you have for those of us who want to, to the > extent possible, keep systemd as nothing more than the first program > to be booted, and want to reduce as much as possible what other > programs need to know about systemd and what systemd needs to know > about the programs I run? I don't have any tips for this, since this isn't a goal of mine; someone else might, though. -- Don Armstrong http://www.donarmstrong.com Build a fire for a man, an he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Jules Bean -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805175341.gh2...@rzlab.ucr.edu
Re: End of hypocrisy, beginning of reason
On Tue, 5 Aug 2014 12:32:48 -0400 Steve Litt wrote: >When I switch to systemd, I'd like to have it as isolated as humanly >possible, just because I'm a modularity kind of guy. I've been watching the thread here... and I understand the thought of not changing from sysvinit because sysvinit works well [sometimes] ... But here you've made a point that should lead you directly to use systemd over sysvinit... especially Debian styled sysvinit. Note this snippet of documentation from Fedora's systemd documentation. ... systemd has the concept of targets which is a more flexible replacement for runlevels in sysvinit. Run level 3 is emulated by multi-user.target. Run level 5 is emulated by graphical.target. runlevel3.target is a symbolic link to multi-user.target and runlevel5.target is a symbolic link to graphical.target. You can switch to 'runlevel 3' by running ... Source: https://fedoraproject.org/wiki/Systemd#How_do_I_change_the_target_.28runlevel.29_.3F In Debian sysvinit, there are pretty much 2 runlevels. Sure, the user can configure the init scripts to run at the "correct" moment during the boot process, but systemd brings a huge advantage to the table by discarding the idea of large slots to start things. It's like going from 8 character long file names in MS DOS to 255 in a *nix environment. I understand the desire of"K.I.S.S.", but the reality is that sysvinit is already massively complex and for all intents and purposes is monolithic in nature. As a side note: I've converted all my personal machines to systemd, and I've yet to run into any problems. I don't usually use the systemd utilities to start and stop services or check logs, but that's mostly habit rather than an actually problem with systemd. In some cases, I have noticed that the verbosity is on the thinner side with journald -- but it's likely there's a setting somewhere that will change that to my liking. Lastly, if sysvinit is no longer a component of any major distro -- likely true -- then sysvinit will quickly go unmaintained. Regardless of the desire to change, it's better to get onboard [whether it's kicking and screaming or just bobbing along with the crowd] rather than remain on the platform holding the bag of growing vulnerabilities... Just these 6 cents -- and out... --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805130559.27d744eba507e6d01496b...@1024bits.com
Re: End of hypocrisy, beginning of reason
On Tue, 5 Aug 2014 09:17:15 -0700 Don Armstrong wrote: > On Tue, 05 Aug 2014, Slavko wrote: > > To be precise, i often read about these things: monolitic, binary > > files and boot speed. I don't like first two and i am not interested > > in latest. > > These are just accessible reasons. The main reason that I personally > voted for systemd over sysv is because systemd (and upstart) provide > correct boot sequencing in complex boot situations. > > For example, if you're using iscsi, and need to start a daemon after > the network is up, iscsi is connected, lvm has resynced, and the > appropriate filesystems are mounted, this is trivial using systemd or > upstart, but very difficult using sysv.[1] > > The other reason is we also get rid of thousands of lines of > difficult-to-maintain boilerplate in init scripts. > > While sysv may be easier to debug in simple systems, there's a reason > why none of the CTTE members (myself included) voted for it. > > 1: Not impossible, but you basically end up replicating a dependency > boot system in shell, and necessarily introduce brittleness and > delays. Cool! Finally someone who knows it and is on the ground floor. I have some questions... When I switch to systemd, I'd like to have it as isolated as humanly possible, just because I'm a modularity kind of guy. I'm thinking of starting the minimum possible daemons with systemd, and starting the rest with daemontools. Of course, I've never before had to manage run order in daemontools, so that might be a little challenging, but I think I can handle it, even if I have to pull off a kludge. Another challenge will be to prevent systemd from starting the daemons I want to launch with daemontools, even though the package installer tells systemd to launch those programs. Is it pretty easy to tell systemd not to launch specific daemons? I will, as usual when I use Debian, start my desktop environment with startx or xinit. I usually use Xfce, LXDE, Openbox, dwm or i9. Do you think I'll have systemd dependencies with those de's started with startx or xinit? What other tips would you have for those of us who want to, to the extent possible, keep systemd as nothing more than the first program to be booted, and want to reduce as much as possible what other programs need to know about systemd and what systemd needs to know about the programs I run? Thanks, SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805123248.261c9...@mydesq2.domain.cxm
