From pmui at groundworkopensource.com Wed Nov 7 07:05:43 2007 From: pmui at groundworkopensource.com (Peter Mui) Date: Wed, 7 Nov 2007 07:05:43 -0800 Subject: BayLISA Monitoring SIG, Weds Nov 14, 7PM Message-ID: <7E8267F1-6EF9-4BBC-9570-4B587768EFD2@groundworkopensource.com> (Hi: You're invited to the BayLISA Monitoring SIG, Weds Nov 14, 7PM. See the meeting announcement pasted below: feel free to post it and/or forward it along to anyone else who might be interested. Many thanks, and hope to see you there! -Peter) ================================================= Nov. 2007 BayLISA Monitoring SIG: How NOT to Install Nagios SIG member Lois G. reports: I did get Nagios installed and Apache serving up the interface. The configuration is all wrong, so it is not monitoring. My idea for presenting is: a beginner's "how to" with audience participation to go through my files and show what I did wrong. In other words, the theme would be "How NOT to Install Nagios." So come ready to help Lois get her monitoring working, share your own Nagios experiences, good and bad, and be prepared to ask probing questions. Or bring the requirements for your proposed monitoring deployment and we'll peruse it for obvious and not-so-obvious gotchas. What: BayLISA Monitoring SIG XII: How NOT to Install Nagios Who: Anyone interested in IT monitoring issues and tools (newbies particularly welcome!) When: Wednesday, Nov 14 2007, 7PM Where: GroundWork Open Source, 139 Townsend St., San Francisco How: 139 Townsend St. is very near AT&T Ballpark. It is one and a half blocks from the CalTrain Depot. Take the MUNI N or T trolley to 2nd and King (ballpark stop) or take the 30 or 45 bus (among others) crosstown. Free evening street parking can probably be found, but there are also several fee-based parking garages around in case of street parking difficulty. Cost: Free!! Piping hot pizza, curiously refreshing pop, and scintillating snacks provided by GroundWork. We'll open up the doors at 6:30 or so and start the formal part of the meeting promptly at 7PM. RSVP (not necessary, but helpful): Peter Mui, pmui at groundworkopensource.com , 415 992 4573 www.groundworkopensource.com ================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: From extasia at extasia.org Wed Nov 7 12:15:49 2007 From: extasia at extasia.org (David Alban) Date: Wed, 7 Nov 2007 12:15:49 -0800 Subject: using redhat chkconfig for logical booleans Message-ID: <4c714a9c0711071215q2afa037eydae67e92d9aab270@mail.gmail.com> Greetings, Many of you may remember the irix implementation of chkconfig. Basically, it managed a set of "features". Each feature could be "on" or "off". The chkconfig command could add a feature to the set, delete a feature from the set, display the current status (on vs. off) of one, several, or all features in the set, and change the status of features in the set. Many irix init.d scripts would check the state of a feature and act accordingly. But any other program could at any time, also query the state of a feature. So you ended up with an implementation of a set of arbitrary logical booleans. The state of each of these booleans was kept in a file: /etc/config/$FEATURE_NAME which contained, literally the word 'on' or the word 'off''. Red Hat took this and modified it so that adding a new feature essentially created hard links from rcN.d directories to /etc/init.d/ scripts. Removing a feature would delete the rcN.d links. You could add/delete features from different run levels At my company, developers have started using *.flag files. Processes test whether a flag file related to a logical boolean exists, and act accordingly. This seems to me to indicate they have requirements to manage a set of logical booleans. But they're not using a single program to manage/report on states. This sounds like trouble to me. I got to thinking, why not use red hat's chkconfig for this, instead (we're a red hat shop)? While not specifically tied to startup, startup processes could indeed use chkconfig to determine system behavior at startup, but other non-startup processes could check states this way as well. Of course, we'd have to be mindful of red hat chkconfig's additional capability of keeping a set of logical booleans per runlevel. I wanted to ask if anyone on the list thought that using red hat's chkconfig to manage logical booleans (or, "features") was a bad idea. Could anyone think of a situation where this could affect us negatively down the road? Or do you think it's generally a good way to manage these "features". In the unlikely event that we change platforms to a different unix, we could easily implement an irix-like chkconfig to perform this functionality. Would not be a large effort. Thanks, David -- Live in a world of your own, but always welcome visitors. From cerise at armory.com Wed Nov 7 13:04:54 2007 From: cerise at armory.com (cerise at armory.com) Date: Wed, 7 Nov 2007 13:04:54 -0800 Subject: using redhat chkconfig for logical booleans In-Reply-To: <4c714a9c0711071215q2afa037eydae67e92d9aab270@mail.gmail.com> References: <4c714a9c0711071215q2afa037eydae67e92d9aab270@mail.gmail.com> Message-ID: <20071107210454.GA32678@boogeyman> Hi David: I thought a long time ago about implementing a lightweight filesystem mounted at /etc for a similar idea. The idea isn't necessarily a bad one, but I think you'll spend a great deal of time trying to hack every program's reading of an /etc config file into your scheme -- that's eventually what prompted me to give up on it. Incidentally, this is essentially what Microsoft did with the system registry. It mostly works. OS X implemented a similar thing in netinfo (IIRC). I'm not sure if the source for that is open, but that may help you out some. Ultimately though, I think you'd be better served writing your own library and utility for those changes than trying to hack it into Red Hat's chkconfig. It'll save you some maintenance headaches the next time Red Hat releases a new version. -Phil On Wed, Nov 07, 2007 at 12:15:49PM -0800, David Alban wrote: > Greetings, > > Many of you may remember the irix implementation of chkconfig. > Basically, it managed a set of "features". Each feature could be "on" > or "off". The chkconfig command could add a feature to the set, > delete a feature from the set, display the current status (on vs. off) > of one, several, or all features in the set, and change the status of > features in the set. > > Many irix init.d scripts would check the state of a feature and act > accordingly. But any other program could at any time, also query the > state of a feature. > > So you ended up with an implementation of a set of arbitrary logical > booleans. The state of each of these booleans was kept in a file: > > /etc/config/$FEATURE_NAME > > which contained, literally the word 'on' or the word 'off''. > > Red Hat took this and modified it so that adding a new feature > essentially created hard links from rcN.d directories to /etc/init.d/ > scripts. Removing a feature would delete the rcN.d links. You could > add/delete features from different run levels > > At my company, developers have started using *.flag files. Processes > test whether a flag file related to a logical boolean exists, and act > accordingly. This seems to me to indicate they have requirements to > manage a set of logical booleans. But they're not using a single > program to manage/report on states. This sounds like trouble to me. > > I got to thinking, why not use red hat's chkconfig for this, instead > (we're a red hat shop)? While not specifically tied to startup, > startup processes could indeed use chkconfig to determine system > behavior at startup, but other non-startup processes could check > states this way as well. Of course, we'd have to be mindful of red > hat chkconfig's additional capability of keeping a set of logical > booleans per runlevel. > > I wanted to ask if anyone on the list thought that using red hat's > chkconfig to manage logical booleans (or, "features") was a bad idea. > Could anyone think of a situation where this could affect us > negatively down the road? Or do you think it's generally a good way > to manage these "features". > > In the unlikely event that we change platforms to a different unix, we > could easily implement an irix-like chkconfig to perform this > functionality. Would not be a large effort. > > Thanks, > David > -- > Live in a world of your own, but always welcome visitors. From extasia at extasia.org Wed Nov 7 13:19:42 2007 From: extasia at extasia.org (David Alban) Date: Wed, 7 Nov 2007 13:19:42 -0800 Subject: [baylisa] Re: using redhat chkconfig for logical booleans In-Reply-To: <20071107210454.GA32678@boogeyman> References: <4c714a9c0711071215q2afa037eydae67e92d9aab270@mail.gmail.com> <20071107210454.GA32678@boogeyman> Message-ID: <4c714a9c0711071319hf651631t476d0a12356f15cb@mail.gmail.com> thanks, phil. i was thinking that chkconfig was one thing that redhat probably wouldn't change very much, due to it being entrenched in the start up sequence. On 11/7/07, cerise at armory.com wrote: > Ultimately though, I think you'd be better served writing your own > library and utility for those changes than trying to hack it into > Red Hat's chkconfig. It'll save you some maintenance headaches > the next time Red Hat releases a new version. -- Live in a world of your own, but always welcome visitors. From asheesh at asheesh.org Wed Nov 7 13:12:26 2007 From: asheesh at asheesh.org (Asheesh Laroia) Date: Thu, 8 Nov 2007 06:12:26 +0900 (JST) Subject: using redhat chkconfig for logical booleans In-Reply-To: <20071107210454.GA32678@boogeyman> References: <4c714a9c0711071215q2afa037eydae67e92d9aab270@mail.gmail.com> <20071107210454.GA32678@boogeyman> Message-ID: On Wed, 7 Nov 2007, cerise at armory.com wrote: > Hi David: > > I thought a long time ago about implementing a lightweight filesystem > mounted at /etc for a similar idea. The idea isn't necessarily a bad > one, but I think you'll spend a great deal of time trying to hack > every program's reading of an /etc config file into your scheme -- > that's eventually what prompted me to give up on it. > On Wed, Nov 07, 2007 at 12:15:49PM -0800, David Alban wrote: >> Greetings, >> >> Many of you may remember the irix implementation of chkconfig. >> Basically, it managed a set of "features". Each feature could be "on" >> or "off". The chkconfig command could add a feature to the set, >> delete a feature from the set, display the current status (on vs. off) >> of one, several, or all features in the set, and change the status of >> features in the set. >> >> Many irix init.d scripts would check the state of a feature and act >> accordingly. But any other program could at any time, also query the >> state of a feature. >> >> So you ended up with an implementation of a set of arbitrary logical >> booleans. The state of each of these booleans was kept in a file: >> >> /etc/config/$FEATURE_NAME >> >> which contained, literally the word 'on' or the word 'off''. You might want to check out the Solaris Service Management Framework. http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.jsp is some official docmentation, which looks pretty good; http://www.oreilly.com/pub/a/sysadmin/2006/04/13/using-solaris-smf.html seems to be a longer article that may be worth taking a look at, too, based on a quick skim. OpenSolaris is Free Software, in case you haven't been carefully following Sun's openness strategies of late. -- Asheesh. -- Traveling through hyperspace isn't like dusting crops, boy. -- Han Solo From bill at wards.net Wed Nov 7 13:55:07 2007 From: bill at wards.net (Bill Ward) Date: Wed, 7 Nov 2007 13:55:07 -0800 Subject: Fwd: [PenLUG] The PenLUG meeting happens this Thursday -- two weeks earlier than usual due to holiday events in November and December. In-Reply-To: <1194419943.5867.7.camel@localhost.localdomain> References: <1194419943.5867.7.camel@localhost.localdomain> Message-ID: <3d2fe1780711071355ma3fbd7bi346ff3f45021bcc8@mail.gmail.com> The meeting is tomorrow! Hope to see you there... RSVP by mail to rsvp at penlug.org or http://upcoming.yahoo.com/event/312327/ ---------- Forwarded message ---------- From: Lee McKusick Date: Nov 6, 2007 11:19 PM Subject: [PenLUG] The PenLUG meeting happens this Thursday -- two weeks earlier than usual due to holiday events in November and December. To: penlug-members at penlug.org The PenLUG meeting happens this Thursday -- two weeks earlier than usual due to holiday events in November and December. Here is what is coming: Date: Thursday, November 8th, 2007 Time: meeting 7:00 - 9:00 PM, social/networking until 10 PM Location: Bayshore Technology Park 1300 Island Drive Redwood City, CA 94065 Suite 106 - Training Room Robert Scott, Linux-based car computer Robert Scott is working on a Linux and Open Source based car computer, and will give a presentation about it which will cover the following areas: * Motivations behind the open source car stereo. * Design goals. * Design decisions. * Some sample code. * Demonstration throughout the supplement the presentation. Robert Scott is currently working as a Software Developer at Untangle. A few years ago he started looking for a way to access a network of applications in a car. Dissatisfied with the current solutions, he decided to take on this challenge during his free time, and cadvium was born. Robert, a strong believer in Open Source, releases most the software for cadvium under GPLv2. Before Untangle, Robert worked a Mykotronx Inc, and completed his undergraduate studies in computer science in 2002. _______________________________________________ PenLUG-Members mailing list PenLUG-Members at penlug.org http://www.penlug.org/mailman/listinfo/penlug-members -------------- next part -------------- An HTML attachment was scrubbed... URL: From extasia at extasia.org Wed Nov 7 14:19:46 2007 From: extasia at extasia.org (David Alban) Date: Wed, 7 Nov 2007 14:19:46 -0800 Subject: [baylisa] Re: using redhat chkconfig for logical booleans In-Reply-To: References: <4c714a9c0711071215q2afa037eydae67e92d9aab270@mail.gmail.com> <20071107210454.GA32678@boogeyman> Message-ID: <4c714a9c0711071419i5882e953sef77f736a61290a0@mail.gmail.com> On 11/7/07, Asheesh Laroia wrote: > http://www.oreilly.com/pub/a/sysadmin/2006/04/13/using-solaris-smf.html > seems to be a longer article that may be worth taking a look at, too, > based on a quick skim. Huh. Maybe it isn't unreasonable to expect that some day soon red hat's chkconfig system will be 'legacy'... -- Live in a world of your own, but always welcome visitors. From jmturner at yahoo-inc.com Sun Nov 11 07:59:06 2007 From: jmturner at yahoo-inc.com (James M. Turner) Date: Sun, 11 Nov 2007 07:59:06 -0800 Subject: Board Elections This Month! Message-ID: <473726CA.6070402@yahoo-inc.com> Dear BayLISA Members (and those who until recently were), This coming Thursday's meeting will be our yearly elections! There are up to 7 seats on the board up for election this year. As there will be no electronic voting this year, please plan to attend this meeting and help guide the future of the organization. All members of BayLISA are eligible to vote; even those who join Thursday evening. Thursday will be a great opportunity to renew for another year, or to treat a friend to a gift membership. :) As an added incentive to your participation, anyone who stands for board, is elected *and* accepts the post will receive a free membership for the coming year (and they don't have to be a member to begin with.) We're looking forward to seeing you there on Thursday night! And just in case you haven't joined us in a while, the meeting will be held in our usual place, Yahoo! Building E, Classroom 9. Directions can be found here: http://yhoo.client.shareholder.com/press/address.cfm Sincerely, Your BayLISA Board of Directors From pmui at groundworkopensource.com Tue Nov 13 10:36:55 2007 From: pmui at groundworkopensource.com (Peter Mui) Date: Tue, 13 Nov 2007 10:36:55 -0800 Subject: Reminder: BayLISA Monitoring SIG Tomorrow, Weds Nov 14, 7PM Message-ID: (Hi: Just a friendly reminder of the BayLISA Monitoring SIG tomorrow, Weds Nov 14, 7PM. See the meeting announcement pasted below: feel free to post it and/or forward it along to anyone else who might be interested. Many thanks, and hope to see you there! -Peter) ================================================= Nov. 2007 BayLISA Monitoring SIG: How NOT to Install Nagios SIG member Lois G. reports: I did get Nagios installed and Apache serving up the interface. The configuration is all wrong, so it is not monitoring. My idea for presenting is: a beginner's "how to" with audience participation to go through my files and show what I did wrong. In other words, the theme would be "How NOT to Install Nagios." So come ready to help Lois get her monitoring working, share your own Nagios experiences, good and bad, and be prepared to ask probing questions. Or bring the requirements for your proposed monitoring deployment and we'll peruse it for obvious and not-so-obvious gotchas. What: BayLISA Monitoring SIG XII: How NOT to Install Nagios Who: Anyone interested in IT monitoring issues and tools (newbies particularly welcome!) When: Wednesday, Nov 14 2007, 7PM Where: GroundWork Open Source, 139 Townsend St., San Francisco How: 139 Townsend St. is very near AT&T Ballpark. It is one and a half blocks from the CalTrain Depot. Take the MUNI N or T trolley to 2nd and King (ballpark stop) or take the 30 or 45 bus (among others) crosstown. Free evening street parking can probably be found, but there are also several fee-based parking garages around in case of street parking difficulty. Cost: Free!! Piping hot pizza, curiously refreshing pop, and scintillating snacks provided by GroundWork. We'll open up the doors at 6:30 or so and start the formal part of the meeting promptly at 7PM. RSVP (not necessary, but helpful): Peter Mui, pmui at groundworkopensource.com , 415 992 4573 ================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam at riihi.com Tue Nov 13 11:43:06 2007 From: sam at riihi.com (Sam J. Juvonen) Date: Tue, 13 Nov 2007 11:43:06 -0800 Subject: Board Elections This Month! In-Reply-To: <473726CA.6070402@yahoo-inc.com> References: <473726CA.6070402@yahoo-inc.com> Message-ID: <4cad3e500711131143t7aeb7c2exad835ea4739dc54e@mail.gmail.com> To clarify, this is Nov 15 at 7:30, is that correct? I suppose I should join and pay my dues instead of slinking in and out of meetings ;-) -Sam. On 11/11/07, James M. Turner wrote: > Dear BayLISA Members (and those who until recently were), > > > This coming Thursday's meeting will be our yearly elections! There are > up to 7 seats on the board up for election this year. As there will be > no electronic voting this year, please plan to attend this meeting and > help guide the future of the organization. > > All members of BayLISA are eligible to vote; even those who join > Thursday evening. Thursday will be a great opportunity to renew for > another year, or to treat a friend to a gift membership. :) > > As an added incentive to your participation, anyone who stands for > board, is elected *and* accepts the post will receive a free membership > for the coming year (and they don't have to be a member to begin with.) > > We're looking forward to seeing you there on Thursday night! And just > in case you haven't joined us in a while, the meeting will be held in > our usual place, Yahoo! Building E, Classroom 9. Directions can be > found here: http://yhoo.client.shareholder.com/press/address.cfm > > > Sincerely, > > > Your BayLISA Board of Directors > > From rick at linuxmafia.com Tue Nov 13 13:39:01 2007 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 13 Nov 2007 13:39:01 -0800 Subject: Board Elections This Month! In-Reply-To: <4cad3e500711131143t7aeb7c2exad835ea4739dc54e@mail.gmail.com> References: <473726CA.6070402@yahoo-inc.com> <4cad3e500711131143t7aeb7c2exad835ea4739dc54e@mail.gmail.com> Message-ID: <20071113213900.GI6823@linuxmafia.com> Quoting Sam J. Juvonen (sam at riihi.com): > To clarify, this is Nov 15 at 7:30, is that correct? I suppose I > should join and pay my dues instead of slinking in and out of meetings > ;-) Right you are. I won't be able to attend because of a conflicting obligation (which is unfortunate, as I'm BayLISA's Treasurer), but Alan and other Board members will happily take your $40 cheque ($15 for students). Alternatively, you can PayPal your money to payment at baylisa.org . -- Cheers, "Reality is not optional." Rick Moen -- Thomas Sowell rick at linuxmafia.com From ahorn at deorth.org Thu Nov 15 13:25:07 2007 From: ahorn at deorth.org (Alan Horn) Date: Thu, 15 Nov 2007 13:25:07 -0800 (PST) Subject: BayLISA November general meeting : 7:30pm tonight at Yahoo Message-ID: <20071115132112.E63359@slick.sigje.org> This month we have had difficult time finding a speaker, so we'll be doing a more discussion-oriented format led by our very own Guy Purcell. We'll be doing OS comparisons, hiring local sysadmins vs outsourcing, and a few other topics. We'll have the usual pizza and sodas, and this months meeting is also where we VOTE IN SOME NEW BOARD MEMBERS ;) Seriously, run for board (you can vote for yourself). We need the help, and if you aren't a member, and you get elected to board and take the post, BayLISA will give you a free membership for the year, thats got to be worth something! :) See you this evening. Cheers, Al From david at catwhisker.org Mon Nov 19 13:43:11 2007 From: david at catwhisker.org (David Wolfskill) Date: Mon, 19 Nov 2007 13:43:11 -0800 Subject: xbiff-like program to monitor remote mailbox? Message-ID: <20071119214311.GS7943@bunrab.catwhisker.org> This may well be a self-inflicted wound, but I'd kinda like to find a reasonably elegant way around it regardless.... I've managed to acquire the habit (for work) of running mutt(1) on my desktop, but configuring mutt to access the IMAP4 server through an SSH tunnel. (Were I to merely run mutt(1) on the machine where the IMAP4 server is running, this would not be an issue -- but there would be other issues I'd rather avoid.) [Oh -- and courtesy of a suggestion from Rick Moen, I run mutt(1) from within screen(1), which is definitely handy -- especially since the display & keyboard I use for access to nearly everything is the set on my laptop.) This has generally worked pretty well for the last couple of years; indeed, I've become rather a fan of doing things via SSH tunnels. One of the things that made this approach relatively palatable despite the hysteresis mutt(1) exhibts with respectto noticing changes in the mailbox has been that the machine where IMAP4 was running also happened to have some miscellaneous bits & pieces of X11 installed on it: enough that I was able to run xbiff(1) on the machine and have it display back to wherever I was (which was usually on my laptop). Over the weekend, we did a "forklift upgrade" to the machine where IMAP4 was running, and while the hardware & software are all shiny now, one of the "casualties" was that we deliberately decided that there wasn't really enough need to have X11 stuff installed on a headless rack-mounted box in a data center to warrant the additional complication. As a result, no xbiff(1) any more. This isn't catastrophic -- I think I was the only one to use it, and since I was the one responsible for implementing the upgrade... well, you get the picture. :-} I've looked around at various {x,}biff-like programs, but each seems to want to look at a local file-like object, and the ones that can flip X-based widgets around tend (for some odd reason) to require X libraries, at least. I think what I want is something that can run on a system that supports X, but that has a somewhat more general way to determine the salient attributes of a mailbox (which may well reside on a remote machine). Any suggestions? Thanks! Peace, david -- David H. Wolfskill david at catwhisker.org Proprietary data formats obfuscate, rather than disseminate, information. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From windsor at warthog.com Mon Nov 19 14:30:59 2007 From: windsor at warthog.com (Rob Windsor) Date: Mon, 19 Nov 2007 16:30:59 -0600 Subject: xbiff-like program to monitor remote mailbox? In-Reply-To: <20071119214311.GS7943@bunrab.catwhisker.org> References: <20071119214311.GS7943@bunrab.catwhisker.org> Message-ID: <47420EA3.9030904@warthog.com> David Wolfskill wrote: > I think what I want is something that can run on a system that supports > X, but that has a somewhat more general way to determine the salient > attributes of a mailbox (which may well reside on a remote machine). > > Any suggestions? custom-build of xbiff and link it static? (although with X11, that'll get ugly-big) Rob++ -- Internet: windsor at warthog.com __o Life: Rob at Carrollton.Texas.USA.Earth _`\<,_ (_)/ (_) "They couldn't hit an elephant at this distance." -- Major General John Sedgwick From david at catwhisker.org Mon Nov 19 15:18:24 2007 From: david at catwhisker.org (David Wolfskill) Date: Mon, 19 Nov 2007 15:18:24 -0800 Subject: [baylisa] xbiff-like program to monitor remote mailbox? In-Reply-To: <20071119144613.M85467@escape.org> References: <20071119214311.GS7943@bunrab.catwhisker.org> <20071119144613.M85467@escape.org> Message-ID: <20071119231824.GT7943@bunrab.catwhisker.org> On Mon, Nov 19, 2007 at 02:46:13PM -0800, Marco Nicosia wrote: > David Wolfskill (david at catwhisker.org) wrote: > > I think what I want is something that can run on a system that supports > > X, but that has a somewhat more general way to determine the salient > > attributes of a mailbox (which may well reside on a remote machine). > > Well, if you just want an imap-enabled xbiff program, it looks > like there are lots of options: > > http://search.yahoo.com/search?p=imap+xbiff&ei=UTF-8&fr=moz2 Hmm... thanks; some of those look as if they might be worth creating a port (since I didn't see one for some of them): catmint(6.3-P)[34] make search key=imapbiff catmint(6.3-P)[35] make search key=xlassie catmint(6.3-P)[36] make search key=tkbiff catmint(6.3-P)[37] make search key=althea (That last has a port: "Yet another GTK-based mail reader for X. Supports IMAP" -- that's probably a bit of overkill for the application in question, though.) Maybe I'll do something useful about it yet.... :-} Peace, david -- David H. Wolfskill david at catwhisker.org Proprietary data formats obfuscate, rather than disseminate, information. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From marco at escape.org Mon Nov 19 14:46:13 2007 From: marco at escape.org (Marco Nicosia) Date: Mon, 19 Nov 2007 14:46:13 -0800 Subject: [baylisa] xbiff-like program to monitor remote mailbox? In-Reply-To: <20071119214311.GS7943@bunrab.catwhisker.org>; from david@catwhisker.org on Mon, Nov 19, 2007 at 01:43:11PM -0800 References: <20071119214311.GS7943@bunrab.catwhisker.org> Message-ID: <20071119144613.M85467@escape.org> David Wolfskill (david at catwhisker.org) wrote: > I think what I want is something that can run on a system that supports > X, but that has a somewhat more general way to determine the salient > attributes of a mailbox (which may well reside on a remote machine). Well, if you just want an imap-enabled xbiff program, it looks like there are lots of options: http://search.yahoo.com/search?p=imap+xbiff&ei=UTF-8&fr=moz2 > -- > David H. Wolfskill david at catwhisker.org > Proprietary data formats obfuscate, rather than disseminate, information. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. _______________________________________________________________________ Marco E. Nicosia | http://www.escape.org/~marco/ | marco at escape.org From dtm at smuckola.org Mon Nov 19 16:04:12 2007 From: dtm at smuckola.org (Dan Bethe) Date: Mon, 19 Nov 2007 16:04:12 -0800 (PST) Subject: [baylisa] xbiff-like program to monitor remote mailbox? In-Reply-To: <20071119231824.GT7943@bunrab.catwhisker.org> Message-ID: <198150.38429.qm@web51703.mail.re2.yahoo.com> Is this a job for gkrellm? Description and screenshot: http://freshmeat.net/projects/gkrellm/ ____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ From sam at riihi.com Mon Nov 19 17:18:10 2007 From: sam at riihi.com (Sam J. Juvonen) Date: Mon, 19 Nov 2007 17:18:10 -0800 Subject: [baylisa] xbiff-like program to monitor remote mailbox? In-Reply-To: <198150.38429.qm@web51703.mail.re2.yahoo.com> References: <20071119231824.GT7943@bunrab.catwhisker.org> <198150.38429.qm@web51703.mail.re2.yahoo.com> Message-ID: <4cad3e500711191718u62dafcb7j39d94695804bc25@mail.gmail.com> I think most of today's desktop environments come with a plugin for this. At this minute I'm on Sol10 "Sun Java Desktop System" (aka Gnome) and even here is a panel plugin for checking mail (local/imap/pop). BTW, first one to come up with an implementation of a two layer password scheme (one of checking, one for reading) in an IMAP server gets a cookie from me. If you're a window manager + xterms kind of guy, somebody must have written a dock-app that works with your WM. I know I used some before I succumbed to the monster Desktop Environments. -sam. On 11/19/07, Dan Bethe wrote: > Is this a job for gkrellm? Description and screenshot: > > http://freshmeat.net/projects/gkrellm/