On Tue, Jun 11, 2013 at 11:16:54PM -0700, Rick Moen wrote:
I respect Abine's offerings very much. For a proprietary software company, they seem extremely benign and very nice people.
Abine is the company that took the indispensible Targeted Advertising Cookie Opt-Out (TACO) project proprietary, _but_ they then cooperated and shared information with the subsequent open-source fork from the last open-source version of TACO, a very nice project called BeefTaco.
ah, didn't realise that. I first encountered Abine's plugin when I started using Chromium....Adblock Plus exists on Chromium, but the script-blocking plugins are nowhere near as good as NoScript on firefox (and not as reliable due to the way Chromium works). Abine's DNT blocked tracking bugs, which is a big part of the reason I disable scripting by default and only enable it for some sites. When I switched back to Firefox, i missed it and went looking for the same thing....found they had a firefox plugin too. I still use Chromium (I've got about half a dozen browsers installed and use them all for different reasons, some only for 1 or 2 specific sites), but I just don't trust it as much as I do Firefox...e.g. the inability to reliably block scripts everywhere serves Google's purposes, not mine. The Task Manager is about the only thing I miss from chromium that I wish was in firefox - being able to see which particular tab or window has gone apeshit and is using up 100% CPU and killing it is extremely useful.
I personally am reluctant to run proprieary extensions, but others will no doubt find great value in that.
me too, usually...but Abine seemed ethical when I checked them out and avoiding tracking ranks higher in my priorities. if BeefTaco does the same/similar thing but open source, then I may switch to that instead.
*.googleapis.com is also a worry...e.g. the number of sites that use jquery hosted from ajax.googleapis.com rather than their own local copy is astounding. don't they realise that that's yet another web bug that potentially allows their users' identities to be linked across multiple sites by google? or do they just not care? developer convenience trumps security.
Very good point. FWIW, I notice that when I use my trick of resolving advertising / tracking / data-mining domains locally [...]
yeah, I can't really do that for googleapis.com, though. some sites I want to use require me to temporarily enable it in NoScript
nice, but i would suggest a script to generate those zone definitions from a simple list of domains. [...]
Oooh, shiny! Thank you, I will have a look at that, after I've sobered up (from the aforementioned Amarone Classico), caught up on a sadly large number of other neglected tasks, etc. I really appreciate your taking the effort. Thanks again.
not all that shiny...more like a functional bit of rusty old iron with some tatty old duct-tape. it's my generic solution to the "I'm bored of making yet another yank-paste-edit config stanza" problem - convert to a simple format for the variable data, a perl script, and a makefile. i've used the method for everything from generating configs for web sites, to mailing lists and their required aliases, to zonefile definitions, zonefiles (many of the zones i created for customers when i was working at an isp were pretty much identical...the name and the main A record were about the only things that varied). anything where I find myself doing the same thing to a predictable pattern with minor variations. writing a script to automate it is more interesting work than doing the repetitive work, and automation brings numerous benefits. it's part of the reason why i never got all that excited by puppet or chef - they just didn't seem all that revolutionary. by the time they came out I'd already been doing similar things for years with bash, perl, ssh, pdsh/pdcp and other tools. the focus of puppet (and chef, and cfengine, and others) was different too, its primary goal was to consistently configure multiple servers to be as similar as possible - which is an undeniably useful and important goal, especially when you have lots of servers or start making very heavy use of virtualisation. but there are still many things that puppet just can't do, or can't do well. puppet is useful for system-level consistency, but not so useful for daemon or service specific configuration. also, I just don't like ruby. or puppet's templating language. I can make puppet do what I want, but it just feels a bit broken and clumsy and incomplete. might be time for another search for an alternative to puppet....hmmm, this looks like a good starting list. http://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_managem... craig -- craig sanders <cas@taz.net.au>