From Michael.Paoli at cal.berkeley.edu Mon Oct 15 14:12:29 2012 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Mon, 15 Oct 2012 14:12:29 -0700 Subject: [buug] BALUG TOMORROW! Tu 2012-10-16 BALUG meeting Message-ID: <20121015141229.1036183pn96nyxc0@webmail.rawbw.com> BALUG TOMORROW! Tu 2012-10-16 BALUG meeting Bay Area Linux User Group (BALUG) meeting TOMORROW Tuesday 6:30 P.M. 2012-10-16 Please RSVP if you're planning to come (see further below). For our 2012-10-16 BALUG meeting, at least presently we don't have a specific speaker/presentation lined up for this meeting, but that doesn't prevent us from having interesting and exciting meetings. Sometimes we also manage to secure/confirm a speaker too late for us to announce or fully publicize the speaker (that's happened at least twice in the past five or so years). Got questions, answers, and/or opinions? We typically have some expert(s) and/or relative expert(s) present to cover LINUX and related topic areas. Want to hear some interesting discussions on LINUX and other topics? Show up at the meeting, and feel free to bring an agenda if you wish. Want to help ensure BALUG has speakers/presentations lined up for future meetings? Help refer speakers to us and/or volunteer to be one of the speaker coordinators. Good food, good people, and interesting conversations to be had. So, if you'd like to join us please RSVP to: rsvp at balug.org **Why RSVP??** Well, don't worry we won't turn you away, but the RSVPs really help BALUG and the Four Seas Restaurant plan the meal and meeting, and with sufficient attendance, they also help ensure that we'll be able to eat upstairs in the private banquet room. Meeting Details... 6:30pm Tuesday, October 16th, 2012 2012-10-16 Four Seas Restaurant http://www.fourseasr.com/ 731 Grant Ave. San Francisco, CA 94108 Easy PARKING: Portsmouth Square Garage at 733 Kearny: http://www.sfpsg.com/ Cost: The meetings are always free, but for dinner, for your gift of $13 cash, we give you a gift of dinner - joining us for a yummy family-style Chinese dinner - tax and tip included (your gift also helps in our patronizing the restaurant venue and helping to defray BALUG costs such treating our speakers to dinner). ------------------------------ Twitter - you can also follow BALUG on Twitter: https://twitter.com/#!/BALUG_org ------------------------------ CDs, and other "door prizes", etc. Goodies we'll have at the meeting (at least the following): We've got some hardware goodies to give away, in addition to available CDs noted below. CDs, etc. - have a peek here: http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc We do also have some additional give-away items, and may have "door prizes". ------------------------------ volunteering to help BALUG Want to volunteer to help out BALUG? (quite a variety of opportunities) Drop us a note at: balug-contact at balug.org Or come talk to us at a BALUG meeting. ------------------------------ Feedback on our publicity/announcements (e.g. contacts or lists where we should get our information out that we're not presently reaching, or things we should do differently): publicity-feedback at balug.org ------------------------------ http://www.balug.org/ From Michael.Paoli at cal.berkeley.edu Thu Oct 18 17:25:09 2012 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Thu, 18 Oct 2012 17:25:09 -0700 Subject: [buug] Why I tend to prefer pax(1) over tar(1) and cpio(1) ... Message-ID: <20121018172509.19005ta9o7uhz544@webmail.rawbw.com> Why I tend to prefer pax(1) over tar(1) and cpio(1) (and some relevant history). The (very) short version. The pax(1) utility is very well standardized (POSIX / Single Unix Specification, etc.), can read and write both tar(1) and cpio(1) format archives, has quite sufficiently flexible means of specifying files to be archived or restored, it's relatively clean, compact, robust code, well does what it needs to do, quite secure, not overburdened with features (it's from OpenBSD), etc., and also lacks some nasty bugs that made it into GNU's implementation of cpio and into production releases of many Linux distributions before being caught and corrected. Once upon a time, before pax(1) and cpio(1), there was tar(1) (and before that ar(1), but we'll not go back *that* far). Now, tar (Tape ARchive), even from "way back then" - at least as far back as 1980, was quite good at the time for arching files of ordinary type (but not block special, character special, etc.) and directories. However it couldn't handle archiving or restoring other file types (e.g. character and block special devices - it would mostly just ignore them), and never has handled backing up or restoring device files. Of course even "way back then", tar wasn't limited to reading/writing archives from tape - it could do so via standard input/output or character or block device file or file of ordinary type. It also was quite limited in how one specified what it did and didn't back up. Specified files were simply archived, and directories, recursively so - with no exception mechanism. Extraction was similarly limited - default was everything, otherwise pathname(s) given were extracted, and if they were an archived directory, the directory was recursively extracted. It used to be the case that tar had some other specific limitations due to its archive format and implementation, but for the most part those aren't significant impediments in modern implementations of tar - or more specifically, the archive formats typically now created by tar. For the most part, cpio came along later. Though it has a history that also goes back fair ways, as far as I'm aware, it was somewhere in the AT&T System V UNIX days, when cpio was released as part of the main/core part of the operating system, rather than only as part of the "text processing system" and associated tools. Anyway, cpio - at least at the time, had many advantages over tar. Most notably, it would backup and restore "special" files - most notably block and character device files (not their contents, but the files themselves). This was very advantageous for doing, e.g. "full system backups", and making recovery a fair bit simpler (as opposed to having to manage to figure out how to recreate all the device files again, and get their permissions/ownerships suitablely back to what they were before). The cpio program also offered a much more convenient mechanism for specifying what was to be backed up (archived), and what was to be restored. When archiving, it reads paths from standard input - very handy when used with find(1). Also very handy when used with any type of program(s) used as filter - so it was much more feasible to do, e.g. a very large system incremental or differential backup with cpio (and suitable filter(s)), as opposed to tar. Use of cpio also gave much more flexible means of specifying what was to be restored. In much of that timeframe, the only other available tools for such were dump(1) and restor(1), which, while rather/quite useful, also had significant limitations (e.g. may not produce good backups or be safely used on active rw mounted filesystems, difficult to do quite selective restores or limited hierarchies, etc.). Anyway, cpio was quite sufficiently good and capable, and not only was it commonly used for backups (and became my generally preferred backup archive format), it was even chosen for other archive applications, e.g. rpm(8). So, cpio - a highly common backup practice was one roughly like this, e.g. for a full system backup: # cd / && find . -depth -print | cpio -o ... or, with GNU cpio and find, to work around one cpio limitation: # cd / && find . -depth -print0 | cpio -o0 ... And that was all fine and good, and worked quite excellently, until ... Well, bugs happen. Along the way, GNU introduced a bug in cpio, a quite annoyingly problematic one, e.g. the common backups (noted above) / and restore: # (cd directory && cpio -idmu < archive_file_or_device) combination no longer worked. GNU cpio doesn't have a "proper" bug tracking system, but it does have a bug email list and archives thereof. http://lists.gnu.org/archive/html/bug-cpio/ A bit easier to follow details on that bug (fortunately since fixed) via Debian's bug tracking system: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458079 In any case, the bug wasn't caught until it was in production/stable releases of many Linux distributions. I'm hoping GNU - and Debian - have added suitable regression tests, so a bug of that nature never makes it into production/stable releases again - particularly given how commonly that backup/restore combination is quite typically used with cpio - and quite depended upon (and not expected to break!). Anyway, still bumping into that bug a lot in various Linux installations (and getting repeatedly annoyed by it), I've come to quite prefer pax. Does not and never had that bug :-) and also much more standard :-) and not overloaded with nonessential and unimportant features (gee, think GNU tar and GNU cpio have enough options yet? Maybe way too many? - at quick approximate count, and not counting alternative forms for same option, I find about 147 options for GNU tar, about 70 for GNU cpio, and about 38 for OpenBSD pax (21 in the standard itself)). "Unix philosophy: Write programs that do one thing and do it well." I certainly think some programs have gotten "too fat" for their own good - that not only often leads to bugs, but often introducing bugs in core program functionality where there were no such bugs before (like breaking cpio in annoying ways, where it was never broken before). Although pax isn't a drop-in replacement for tar or cpio, with suitable adjustments to options, and perhaps adjustment in how one specifies what's to be archived, pax makes a fine replacement for tar and cpio - especially if one sticks to and only was using quite standard (e.g. POSIX / Single Unix Specification) options to tar and cpio. Here's partial "cheat sheet" I still tend to refer to, when using pax in place of cpio (or tar), and their at least approximate equivalents: cpio -it pax cpio -idmu pax -r -p e cpio -0o -H newc pax -w -0d -x sv4cpio cpio -0pdmu directory pax -rw -0d -p e directory cpio -0pdlmu directory pax -rw -0dl -p e directory tar -tf - pax tar -xf - [file ...] pax -r -p e [pattern ...] tar -cf - file [...] pax -w -x ustar file [...] All the pax(1) options I show above are standard, except -0, which is an OpenBSD / GNU style extension (which GNU nicely added to find, cpio, xargs(1), etc., and very nicely solves the problem of dealing with filenames that contain newlines). pax(1) standards: The Open Group Base Specifications Issue 7 IEEE Std 1003.1-2008 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html OpenBSD man page for pax(1): http://www.openbsd.org/cgi-bin/man.cgi?query=pax From centeractive.communities at gmail.com Wed Oct 31 04:23:48 2012 From: centeractive.communities at gmail.com (Centeractive AG) Date: Wed, 31 Oct 2012 12:23:48 +0100 Subject: [buug] New log analysis tool you can find useful Message-ID: Hi, We are a Swiss software company called centeractive ag. We have recently developed what we think is a pretty handy tool for log analysis called Retrospective Log Analyzer (www.retrospective.ch). It?s not a spam message; we are not trying to sell you anything. We would like to offer your community 10 free Retrospective Log Analyzer licences (worth 58$ each) in the hope that we will get some valuable feedback from real users. Communities like yours seem a perfect place for this. For the previous 6 months we have been improving this software and the feedback we have received so far has always been of great value to us. To get your free licence you need to register at: http://community.centeractive.net quoting the following code: US_UNI_1923. Then you can go directly to the download site: www.retrospective.ch Retrospective?s key features are: search / tail (monitoring) of logs on Linux hosts over SSH and on local disks, log entries split, column-split, log4j support, date auto-parsing in logs, and SSH keys support. The Retrospective cartoon presents all these features in a nutshell: http://www.youtube.com/watch?v=1pJn8ZEHRTE We would be very grateful for any comments on our forum: http://forums.centeractive.com/viewforum.php?f=3 Any serious advice/comments will be considered when we prepare the next version. Regards, centeractive ag team -------------- next part -------------- An HTML attachment was scrubbed... URL: