From itz at buug.org Thu Sep 6 22:50:48 2012 From: itz at buug.org (Ian Zimmerman) Date: Thu, 06 Sep 2012 22:50:48 -0700 Subject: [buug] Managing without CUPS Message-ID: <87ipbqqt3b.fsf@foolinux.dyndns.org> At the meeting tonight I mentioned that I no longer use the buggy & bloated CUPS spooler for printing, or any other spooler. Instead, I pass input files through a foomatic-rip pipeline directly to the printer port on a printer server machine, subject only to a UUCP-like locking protocol. Here are the 2 scripts involved: /usr/local/bin/noqp: #! /usr/bin/python # Trivial script for No Queue Printing. import subprocess as SP import getopt import sys import os import select opts, args = getopt.getopt(sys.argv[1:], 'P:J:o:') jobname = None printer = None popts = [] for k, v in opts: if k == '-J': if jobname is not None: sys.stderr.write('Multiple -J options\n') sys.exit(2) jobname = v elif k == '-P': if printer is not None: sys.stderr.write('Multiple -P options\n') sys.exit(2) printer = v elif k == '-o': popts.append(v) # foomatic-rip in no spool mode has no default for -P so we have to # supply it, one way or another if printer is None: try: printer = os.environ['PRINTER'] except KeyError: sys.stderr.write('No -P option and no PRINTER envvar\n') sys.exit(2) if not printer: sys.stderr.write('No -P option and PRINTER envvar empty\n') sys.exit(2) # remote printer details try: host, device = os.environ['NOQP_HOST'], os.environ['NOQP_DEVICE'] except KeyError: sys.stderr.write('NOQP_HOST or NOQP_DEVICE envvar unset\n') sys.exit(2) if not host or not device: sys.stderr.write('NOQP_HOST or NOQP_DEVICE envvar empty\n') # gather arguments for foomatic foomargs = ['-P', printer] if jobname: foomargs.extend(('-J', jobname)) for popt in popts: foomargs,extend(('-o', popt)) # set up the pipeline sp_cat = SP.Popen(['cat'] + args, stdout=SP.PIPE, close_fds=True) sp_rip = SP.Popen(['foomatic-rip'] + foomargs, stdin=SP.PIPE, stdout=SP.PIPE, close_fds=True) sp_ssh = SP.Popen(['ssh', host, 'lockedcat', device], stdin=SP.PIPE, close_fds=True) buf_cat_rip = '' buf_rip_ssh = '' rdict = {'cat': sp_cat.stdout, 'rip': sp_rip.stdout} wdict = {'rip': sp_rip.stdin, 'ssh': sp_ssh.stdin} # limit buffering, otherwise we might read the entire file into memory MAX_BUF = 40 * select.PIPE_BUF while rdict or wdict: if not buf_cat_rip and 'cat' not in rdict and 'rip' in wdict: sp_rip.stdin.close() del wdict['rip'] if not buf_rip_ssh and 'rip' not in rdict and 'ssh' in wdict: sp_ssh.stdin.close() del wdict['ssh'] wlist = [] if 'rip' in wdict and buf_cat_rip: wlist.append(wdict['rip']) if 'ssh' in wdict and buf_rip_ssh: wlist.append(wdict['ssh']) rlist = [] if 'cat' in rdict and len(buf_cat_rip) < MAX_BUF: rlist.append(rdict['cat']) if 'rip' in rdict and len(buf_rip_ssh) < MAX_BUF: rlist.append(rdict['rip']) rset, wset, _ = select.select(rlist, wlist, [], 1.0) if sp_rip.stdin in wset: amount = min(select.PIPE_BUF, len(buf_cat_rip)) sp_rip.stdin.write(buf_cat_rip[:amount]) buf_cat_rip = buf_cat_rip[amount:] if sp_ssh.stdin in wset: amount = min(select.PIPE_BUF, len(buf_rip_ssh)) sp_ssh.stdin.write(buf_rip_ssh[:amount]) buf_rip_ssh = buf_rip_ssh[amount:] if sp_cat.stdout in rset: new_cat = sp_cat.stdout.read(select.PIPE_BUF) if not new_cat: del rdict['cat'] sp_cat.stdout.close() else: buf_cat_rip = buf_cat_rip + new_cat if sp_rip.stdout in rset: new_rip = sp_rip.stdout.read(select.PIPE_BUF) if not new_rip: del rdict['rip'] sp_rip.stdout.close() else: buf_rip_ssh = buf_rip_ssh + new_rip status = 0 for sp in (sp_cat, sp_rip, sp_ssh): sp.wait() if sp.returncode != 0: status = 1 sys.exit(status) /usr/local/bin/lockedcat: #! /bin/sh set -e device="$1" lockfile="/run/lock/LCK..`basename ${device}`" dotlockfile -r 100 -p "${lockfile}" trap "dotlockfile -u ${lockfile}" EXIT HUP TERM INT buffer -p 75 > "${device}" -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png Rule 420: All persons more than eight miles high to leave the court. From togo at of.net Fri Sep 7 15:53:17 2012 From: togo at of.net (Tony Godshall) Date: Fri, 7 Sep 2012 15:53:17 -0700 Subject: [buug] Managing without CUPS In-Reply-To: <87ipbqqt3b.fsf@foolinux.dyndns.org> References: <87ipbqqt3b.fsf@foolinux.dyndns.org> Message-ID: On Thu, Sep 6, 2012 at 10:50 PM, Ian Zimmerman wrote: > > At the meeting tonight I mentioned that I no longer use the buggy & > bloated CUPS spooler for printing, or any other spooler. Instead, I > pass input files through a foomatic-rip pipeline directly to the printer > port on a printer server machine, subject only to a UUCP-like locking > protocol. > > Here are the 2 scripts involved: Might be worth trying to revive PDQ http://www.faqs.org/docs/Linux-HOWTO/Printing-HOWTO.html#PDQ-WHICH-SPOOLER http://www.faqs.org/docs/Linux-HOWTO/Printing-HOWTO.html#PDQ-OVERVIEW which Rick says stagnated around 2006: http://linuxmafia.com/faq/Debian/printing-setup.html Perhaps your Python script could be generalized and and made GUI friendly and published as a modern PDQ rewrite. On the other hand, googling PDQ with various printer-related terms indicates that the name has gotten too overloaded. (e.g. "Founded in 1976, PDQ Printing is Northern California's largest quick printer...") DCUPS might be more unique but it would be a poor choice unless you made some humorous reference to Microsoft-inspired gender insensitivity ... http://linux.slashdot.org/story/12/07/19/1923200/microsoft-apologizes-for-inserting-naughty-phrase-into-linux-kernel noqp is certainly simple to type, but it doesnt exacly roll off the tongue. Suppose it might do. Anyway, thanks for posting your scripts! From rick at linuxmafia.com Fri Sep 7 18:24:47 2012 From: rick at linuxmafia.com (Rick Moen) Date: Fri, 7 Sep 2012 18:24:47 -0700 Subject: [buug] Managing without CUPS In-Reply-To: References: <87ipbqqt3b.fsf@foolinux.dyndns.org> Message-ID: <20120908012446.GS6238@linuxmafia.com> Quoting Tony Godshall (togo at of.net): > Might be worth trying to revive PDQ > > http://www.faqs.org/docs/Linux-HOWTO/Printing-HOWTO.html#PDQ-WHICH-SPOOLER > > http://www.faqs.org/docs/Linux-HOWTO/Printing-HOWTO.html#PDQ-OVERVIEW > > which Rick says stagnated around 2006: > > http://linuxmafia.com/faq/Debian/printing-setup.html Yeah, I was thinking of mentioning that. Seems as if Ian has nicely reimplemented the idea, though! From rick at linuxmafia.com Sat Sep 8 11:08:56 2012 From: rick at linuxmafia.com (Rick Moen) Date: Sat, 8 Sep 2012 11:08:56 -0700 Subject: [buug] Managing without CUPS In-Reply-To: <20120908012446.GS6238@linuxmafia.com> References: <87ipbqqt3b.fsf@foolinux.dyndns.org> <20120908012446.GS6238@linuxmafia.com> Message-ID: <20120908180856.GU6238@linuxmafia.com> I wrote: > Quoting Tony Godshall (togo at of.net): > > > Might be worth trying to revive PDQ > > > > http://www.faqs.org/docs/Linux-HOWTO/Printing-HOWTO.html#PDQ-WHICH-SPOOLER > > > > http://www.faqs.org/docs/Linux-HOWTO/Printing-HOWTO.html#PDQ-OVERVIEW > > > > which Rick says stagnated around 2006: > > > > http://linuxmafia.com/faq/Debian/printing-setup.html > > Yeah, I was thinking of mentioning that. > > Seems as if Ian has nicely reimplemented the idea, though! That page (printing-setup.html) is overdue for a thorough refactoring, isn't it? As it stands, it's sort of an old attic of lore about solving printing problems, including problems with lpr/lprng, both of which are obsolete and should not be touched with a 50-foot barge pole other than putting in shim utilities so more-modern printing subsystems (usually CUPS) can offer a emulation of the lpr service interface to processes that expect it. People might forget just how nasty lpr and lprng were. Yes, CUPS is a _little_ overengineered and overfeatured, when you just want basic local printing, but count your blessings. And, by the way, although the PDQ project was revived by Jeremy C. Reed in 2006, I see that it's not had any commits since 2006, either. Rats. In rare cases, this means a codebase is mature and doesn't have any overwhelmingly worrisome bugs needing fixing (e.g., procmail), but I wouldn't count on it. http://pdq.sourceforge.net http://sourceforge.net/projects/pdq/ Anyway, there's room in Unix for two alternative print systems, one with queuing, accounting/job-control/priorities, and print-serving to remote users on other systems elsewhere (CUPS), and a second one that just... prints. PDQ had a lpr-empulation service interface and a gtk-based administrative and setup utility (xpdf). Quoting the SF.net project's description: 'pdq is a straightforward, flexible print system with modular driver and interface, monitoring, per-user configurations, and root privileges not required. Supports AppleTalk, BSD LPD, efax, hardware. Works with Foomatic and PPD. X client also available.' That really did hit the sweet spot, I think. Shame it hasn't been maintained. From itz at buug.org Sat Sep 8 20:41:55 2012 From: itz at buug.org (Ian Zimmerman) Date: Sat, 08 Sep 2012 20:41:55 -0700 Subject: [buug] Managing without CUPS In-Reply-To: <20120908180856.GU6238@linuxmafia.com> (Rick Moen's message of "Sat, 8 Sep 2012 11:08:56 -0700") References: <87ipbqqt3b.fsf@foolinux.dyndns.org> <20120908012446.GS6238@linuxmafia.com> <20120908180856.GU6238@linuxmafia.com> Message-ID: <87bohfhngc.fsf@foolinux.dyndns.org> Rick> PDQ had a lpr-empulation service interface and a gtk-based Rick> administrative and setup utility (xpdf). Quoting the SF.net Rick> project's description: 'pdq is a straightforward, flexible print Rick> system with modular driver and interface, monitoring, per-user Rick> configurations, and root privileges not required. Supports Rick> AppleTalk, BSD LPD, efax, hardware. Works with Foomatic and PPD. X Rick> client also available.' I actually had a foggy recollection that something like PDQ existed, but rather than firing up the search engine I thought, "How hard can it be, with foomatic having done the real work?" I think I'm gonna prettify it a little, to use a config file instead of environment variables, and perhaps outsource the horrible event loop to a specialized python library. Not all that interested in a GUI, sorry. But maybe I can put it on github and invite contributions :-) -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png Rule 420: All persons more than eight miles high to leave the court. From nkj at iaminsane.com Mon Sep 10 04:21:18 2012 From: nkj at iaminsane.com (Nick Jennings) Date: Mon, 10 Sep 2012 13:21:18 +0200 Subject: [buug] $*#! JavaScript and the new playing field for Free Software Message-ID: Hi All, this is loosely based off Ian Zimmerman's post regarding blocking of JavaScript and the "Brave New Web" as he put it. I'm wondering what you guys think of the advent of 'web-apps' in general. Is your distaste for JavaScript across the board, or do you see benefits when used for a specific purpose (like a web application) and just don't want random JS running as you browse general purpose websites? I've long hated webapps, but as I've continued to give it thought and consider different perspectives I do see a ton of benefits. Namely that JavaScript is quickly becoming the one language that can span across all the different developers of the world and be a common platform we can all use to share and communicate ideas with. We breach platform dependencies (as long as we're not talking about low-level system and driver interfacing software) and the possibilities for free software grow. With projects like unhosted.org, we can decouple the web-app from the server lock-in and keep our own data, become unreliant on server-side app-logic, and can reach a much wider audience. With local storage and increasing performance, we can make apps which operate offline, provide great user interfaces, and even use hardware acceleration. There will never be a replacement for keeping the power of your OS (I hate the concept of the chrome-book), but in many ways the advent of HTML5, the movement to embrace JavaScript rather than put up with it, and web-apps in general, do help to level the playing feild for free operating systems. What do you all think? -Nick From itz at buug.org Mon Sep 10 09:14:10 2012 From: itz at buug.org (Ian Zimmerman) Date: Mon, 10 Sep 2012 09:14:10 -0700 Subject: [buug] $*#! JavaScript and the new playing field for Free Software In-Reply-To: (Nick Jennings's message of "Mon, 10 Sep 2012 13:21:18 +0200") References: Message-ID: <87zk4xetyl.fsf@foolinux.dyndns.org> Nick> There will never be a replacement for keeping the power of your OS Nick> (I hate the concept of the chrome-book), but in many ways the Nick> advent of HTML5, the movement to embrace JavaScript rather than Nick> put up with it, and web-apps in general, do help to level the Nick> playing feild for free operating systems. I cannot see this at all. For me, the trends toward web apps is essentially an end run around free software, as RMS has predicted. And the conspiracy theorist in me is convinced this is quite intentional, i.e. someone somewhere (probably in the US Northwest) in a smoke filled room came up with the idea and saw where it would go. Of course it is not about JavaScript the language which is no uglier than, say, Perl. It is about depending on untrusted, unfixable (unless you control the website) and mostly un-inspectable (with minimization etc.) code. -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png Rule 420: All persons more than eight miles high to leave the court. From itz at buug.org Mon Sep 10 14:56:44 2012 From: itz at buug.org (Ian Zimmerman) Date: Mon, 10 Sep 2012 14:56:44 -0700 Subject: [buug] Managing without CUPS In-Reply-To: <87bohfhngc.fsf@foolinux.dyndns.org> (Ian Zimmerman's message of "Sat, 08 Sep 2012 20:41:55 -0700") References: <87ipbqqt3b.fsf@foolinux.dyndns.org> <20120908012446.GS6238@linuxmafia.com> <20120908180856.GU6238@linuxmafia.com> <87bohfhngc.fsf@foolinux.dyndns.org> Message-ID: <87r4q9ee3n.fsf@foolinux.dyndns.org> Ian> Not all that interested in a GUI, sorry. But maybe I can put it on Ian> github and invite contributions :-) I have now done this: https://github.com/nobrowser/noqp -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png Rule 420: All persons more than eight miles high to leave the court. From rick at linuxmafia.com Mon Sep 10 19:01:53 2012 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 10 Sep 2012 19:01:53 -0700 Subject: [buug] $*#! JavaScript and the new playing field for Free Software In-Reply-To: <87zk4xetyl.fsf@foolinux.dyndns.org> References: <87zk4xetyl.fsf@foolinux.dyndns.org> Message-ID: <20120911020153.GQ6238@linuxmafia.com> Quoting Ian Zimmerman (itz at buug.org): > Of course it is not about JavaScript the language which is no uglier > than, say, Perl. It is about depending on untrusted, unfixable (unless > you control the website) and mostly un-inspectable (with minimization > etc.) code. And in conclusion, yay NoScript and RequestPolicy, which help make JavaScript less of a liability and annoyance. http://linuxmafia.com/~rick/faq/index.php?page=kicking#linuxbrowser From itz at buug.org Mon Sep 10 19:27:57 2012 From: itz at buug.org (Ian Zimmerman) Date: Mon, 10 Sep 2012 19:27:57 -0700 Subject: [buug] $*#! JavaScript and the new playing field for Free Software In-Reply-To: <20120911020153.GQ6238@linuxmafia.com> (Rick Moen's message of "Mon, 10 Sep 2012 19:01:53 -0700") References: <87zk4xetyl.fsf@foolinux.dyndns.org> <20120911020153.GQ6238@linuxmafia.com> Message-ID: <871ui9thsi.fsf@foolinux.dyndns.org> Rick> And in conclusion, yay NoScript and RequestPolicy, which help make Rick> JavaScript less of a liability and annoyance. Rick> http://linuxmafia.com/~rick/faq/index.php?page=kicking#linuxbrowser For now, I have settled on CsFire [1] as my primary means of protection. That, and aggressively growing my /etc/bind/named.conf.local :-) [1] https://addons.mozilla.org/en-US/firefox/addon/csfire/ -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png Rule 420: All persons more than eight miles high to leave the court. From pi at berkeley.edu Mon Sep 10 19:40:11 2012 From: pi at berkeley.edu (Paul Ivanov) Date: Mon, 10 Sep 2012 19:40:11 -0700 Subject: [buug] $*#! JavaScript and the new playing field for Free Software In-Reply-To: <871ui9thsi.fsf@foolinux.dyndns.org> References: <87zk4xetyl.fsf@foolinux.dyndns.org> <20120911020153.GQ6238@linuxmafia.com> <871ui9thsi.fsf@foolinux.dyndns.org> Message-ID: <20120911024011.GF5139@HbI-OTOH.berkeley.edu> Ian Zimmerman, on 2012-09-10 19:27, wrote: > For now, I have settled on CsFire [1] as my primary means of protection. > That, and aggressively growing my /etc/bind/named.conf.local :-) I find w3m to be sufficient protection. Nine times out of ten, a website that requires javascript is one that I don't want to visit, anyway. :) best, -- Paul Ivanov http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From rick at linuxmafia.com Mon Sep 10 19:43:59 2012 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 10 Sep 2012 19:43:59 -0700 Subject: [buug] $*#! JavaScript and the new playing field for Free Software In-Reply-To: <871ui9thsi.fsf@foolinux.dyndns.org> References: <87zk4xetyl.fsf@foolinux.dyndns.org> <20120911020153.GQ6238@linuxmafia.com> <871ui9thsi.fsf@foolinux.dyndns.org> Message-ID: <20120911024359.GL14005@linuxmafia.com> Quoting Ian Zimmerman (itz at buug.org): > For now, I have settled on CsFire [1] as my primary means of protection. It'd be really nice if you could politely suggest to author Philippe De Ryck that he provide a licence statement (as he has created proprietary software by default). Probably MPL 2.0 would be good. Unfortunately, a lot of authors either never think about that matter or mistakenly assume that absence of licence makes something open source. Article: http://archive09.linux.com/feature/155919 > That, and aggressively growing my /etc/bind/named.conf.local :-) You're more than welcome to mine this'un: http://linuxmafia.com/pub/linux/network/bind9-examples-linuxmafia.tar.gz From nick at silverbucket.net Tue Sep 11 06:25:38 2012 From: nick at silverbucket.net (Nick Jennings) Date: Tue, 11 Sep 2012 15:25:38 +0200 Subject: [buug] $*#! JavaScript and the new playing field for Free Software In-Reply-To: <87zk4xetyl.fsf@foolinux.dyndns.org> References: <87zk4xetyl.fsf@foolinux.dyndns.org> Message-ID: Hi Ian, thanks for your response. On Mon, Sep 10, 2012 at 6:14 PM, Ian Zimmerman wrote: > > Nick> There will never be a replacement for keeping the power of your OS > Nick> (I hate the concept of the chrome-book), but in many ways the > Nick> advent of HTML5, the movement to embrace JavaScript rather than > Nick> put up with it, and web-apps in general, do help to level the > Nick> playing feild for free operating systems. > > I cannot see this at all. For me, the trends toward web apps is > essentially an end run around free software, as RMS has predicted. And > the conspiracy theorist in me is convinced this is quite intentional, > i.e. someone somewhere (probably in the US Northwest) in a smoke filled > room came up with the idea and saw where it would go. I would have completely agreed with you a year ago. My first reaction was to stay as far away as possible. > Of course it is not about JavaScript the language which is no uglier > than, say, Perl. It is about depending on untrusted, unfixable (unless > you control the website) and mostly un-inspectable (with minimization > etc.) code. Untrusted only in as far as running something which you cannot easily vet the source of. Which is not the case of open-source webapps, with publically available github repositories. What's the difference between running an open-source webapp or checking out and compiling an open-source native application? Assuming you can address the vendor lock-in (keeping your data on their servers, or the app being dependant on some critical server-side functionality), the only difference is the open-source web-app can reach a broader audience. You bring up a crucial point though. The term 'web-app' has generally been used to encompass a large spectrum of functionality, generally with the application tied to a back-end server and system. However this is what projects like unhosted.org are trying to free users from. To try to influence the 'web-app' movement for the better and liberate peoples data and applications from vendor tie-in. The paradigm is simple. Keep all web-app logic on the client-size (js, css, html), decouple the vendor lock-in by providing a generic library to facility remote-storage (remoteStorage.js) which could just as easily be running on localhost, or on your own server somewhere "in the cloud". The app could be distributed straight from the github repository, or via various open-app channels of your choosing. I also fear the Brave New Web, and consider this an important battle to fight for proponents of Free Software. I hope this at least prompts you to have another look and possibly re-evaluate the situation as you see it, I think there are many ways to look at this problem. -- Nick Jennings www.silverbucket.net From cjr at grundrisse.org Tue Sep 11 09:15:37 2012 From: cjr at grundrisse.org (Claude Rubinson) Date: Tue, 11 Sep 2012 11:15:37 -0500 Subject: [buug] $*#! JavaScript and the new playing field for Free Software In-Reply-To: References: <87zk4xetyl.fsf@foolinux.dyndns.org> Message-ID: <20120911161537.GA4094@wagner> On Tue, Sep 11, 2012 at 03:25:38PM +0200, Nick Jennings wrote: > Untrusted only in as far as running something which you cannot easily > vet the source of. Which is not the case of open-source webapps, with > publically available github repositories. What's the difference > between running an open-source webapp or checking out and compiling an > open-source native application? Assuming you can address the vendor > lock-in (keeping your data on their servers, or the app being > dependant on some critical server-side functionality), the only > difference is the open-source web-app can reach a broader audience. Which is why the AGPL is so important. And why I really wish that the Affero clause had made it into the GPL3. > The paradigm is simple. Keep all web-app logic on the client-size (js, > css, html), decouple the vendor lock-in by providing a generic library > to facility remote-storage (remoteStorage.js) which could just as > easily be running on localhost, or on your own server somewhere "in > the cloud". The app could be distributed straight from the github > repository, or via various open-app channels of your choosing. Aside from the user being in control of where their data is stored, what's the difference between this and the idea of the web browser as the universal frontend (a concept that I think sounds better than it works in practice)? Claude From nick at silverbucket.net Tue Sep 11 15:54:19 2012 From: nick at silverbucket.net (Nick Jennings) Date: Wed, 12 Sep 2012 00:54:19 +0200 Subject: [buug] $*#! JavaScript and the new playing field for Free Software In-Reply-To: <20120911161537.GA4094@wagner> References: <87zk4xetyl.fsf@foolinux.dyndns.org> <20120911161537.GA4094@wagner> Message-ID: On Tue, Sep 11, 2012 at 6:15 PM, Claude Rubinson wrote: > On Tue, Sep 11, 2012 at 03:25:38PM +0200, Nick Jennings wrote: >> The paradigm is simple. Keep all web-app logic on the client-size (js, >> css, html), decouple the vendor lock-in by providing a generic library >> to facility remote-storage (remoteStorage.js) which could just as >> easily be running on localhost, or on your own server somewhere "in >> the cloud". The app could be distributed straight from the github >> repository, or via various open-app channels of your choosing. > > Aside from the user being in control of where their data is stored, > what's the difference between this and the idea of the web browser as > the universal frontend (a concept that I think sounds better than it > works in practice)? Well, decoupling the storage from the vendor is a very significant aspect that changes things quite a bit. In addition, if you have all your app-logic in JavaScript/HTML/CSS client-side, and your storage at a vendor of your choosing (your server, a friends server, a professional storage provider), you nullify the traditional "ASP" paradigm. Regardless of wether the browser is or is not going to be the universal front-end isn't really something we can predict, however there are a tons of cases where web-apps make a lot of sense. So therefore it makes sense to be conscious of the ways in which open-source software can continue to thrive in those environments. -Nick From Michael.Paoli at cal.berkeley.edu Mon Sep 17 14:58:17 2012 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Mon, 17 Sep 2012 14:58:17 -0700 Subject: [buug] BALUG TOMORROW! Tu: Gary Longoria on Scratch; & Raspberry Pi benefit auction! Message-ID: <20120917145817.18243e8wogf8kois@webmail.rawbw.com> BALUG TOMORROW! Tu: Gary Longoria on Scratch; & Raspberry Pi benefit auction! Bay Area Linux User Group (BALUG) meeting TOMORROW Tuesday 6:30 P.M. 2012-09-18 Please RSVP if you're planning to come (see further below). For our 2012-09-18 BALUG meeting, we're please to present Gary Longoria on Scratch, plus: Raspberry Pi benefit auction! Gary Longoria will talk about his experience using Scratch to teach programming to high school students at the UC Berkeley Pre-College Academy during the Summer. [watch the BALUG website for additional details] Raspberry Pi Partimus[1] benefit auction! Want to get your hands on a Raspberry Pi? How about also benefiting a very cool open source and education related cause? You can do both! Partimus has a Raspberry Pi to be auctioned off at this BALUG meeting, all proceeds to go to Partimus. (there may be minimum/reserve price on bidding, details to be covered not later than at the auction itself). [watch the BALUG website for additional details] 1. http://partimus.org/ 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, September 18th, 2012 2012-09-18 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, etc. We'll have CDs noted below available at the meeting, and at least some other goodies too. 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 Sep 20 19:53:27 2012 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Thu, 20 Sep 2012 19:53:27 -0700 Subject: [buug] info(1) / man(1) - view output in a vi(1) session Message-ID: <20120920195327.63603l2yjgjjvnac@webmail.rawbw.com> So, from my "todo" list from several BUUG meetings back, question came up about info(1), and grabbing all its output as plain text, and, e.g., viewing it within a vi(1) session. Well, years ago, I wrote such a script - and in fact it's by far the most common way I'll look at info(1) pages (why learn yet another interface? info(1) might've been a great idea before HTML and web browsers, but after that ... *really*?) Anyway, key bit quite useful with info(1) for such, these options: --subnodes --output The script/program I wrote, I called viewinfo. It can be seen here: http://www.rawbw.com/~mp/unix/sh/examples/viewinfo I probably ought to rewrite it a bit to conditionally use mktemp(1) if it's available, and perhaps make some other modest improvements/tweaks. Similarly, I wrote a script/program, called viewman, for bringing the contents of man(1) pages into a vi(1) session: http://www.rawbw.com/~mp/unix/sh/examples/viewman references/see also: http://www.rawbw.com/~mp/unix/sh/examples/ http://www.rawbw.com/~mp/unix/sh/ vi(1) info(1) man(1) sh(1) col(1) From itz at buug.org Thu Sep 20 22:03:24 2012 From: itz at buug.org (Ian Zimmerman) Date: Thu, 20 Sep 2012 22:03:24 -0700 Subject: [buug] info(1) / man(1) - view output in a vi(1) session In-Reply-To: <20120920195327.63603l2yjgjjvnac@webmail.rawbw.com> (Michael Paoli's message of "Thu, 20 Sep 2012 19:53:27 -0700") References: <20120920195327.63603l2yjgjjvnac@webmail.rawbw.com> Message-ID: <874nmsvug3.fsf@foolinux.dyndns.org> Michael> yet another interface? info(1) might've been a great idea Michael> before HTML and web browsers, but after that ... *really*?) And before emacs(1) :-P Sorry for not showing up tonight, not feeling well. -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png Rule 420: All persons more than eight miles high to leave the court.