Re: Stupid fucking antivirus software
* at 31/08 15:27 +0100 Peter Sergeant said: On Sun, Aug 31, 2003 at 01:54:56PM +0100, David Cantrell wrote: What you are saying is equivalent to if there's money to be made from spamming, there's nothing wrong with doing it.. No, what I'm saying is that expecting businesses to act like charities is more than a little silly. Bouncing messages was added because at the time it was deemed useful by both the anti-virus company and clients, and because clients would pay money for this extra feature. If there is little client demand to improve this feature, then, bizarrely enough, the vendors aren't going to do it. Having said that, I believe more than a few of the vendors do have products that discriminate - it's hardly their fault if sysadmins don't upgrade their software. Ah, but it seems to me that while it's not reasonable to ask a business to act as a charity it is reasonable to ask them to act in such a way as to not inconvience you. I think the issue here is that people always say 'it's easy to delete email' or that the bounces don't cause any real harm. The problem is that it's not true. It's not hard to find people out there (quite a few of whom are on this list) who have had 10s of thousands of innapropriate bounces. When a problem reached that sort of scale I think it's entirely reasonable to expect the companies responsible to alter their products. And while they can't force their users to upgrade, much as I'm sure they'd love to, they can make sure they make attempts to inform their users of the issues. Isn't idealism nice? Struan
Re: insidious biometrics, identity crises
On 29 Aug 2003 at 22:29, Piers Cawley wrote: Michael Stevens [EMAIL PROTECTED] writes: Aah, but what programming language would be best for them to use on such a project? Befunge. Or Brainfuck. Maybe INTERCAL. Malbolge. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: insidious biometrics, identity crises
Elaine -HFB- Ashton [EMAIL PROTECTED] writes: Tony Bowden [EMAIL PROTECTED] quoth: * *You only have to be able to produce your driving license when asked, and *you have up to 7 days to do so. You don't have to be carrying it. Well, I suspect something similar would happen with an ID card. How would they know who to arrest if nobody turned up with the ID card within seven days?
Re: insidious biometrics, identity crises
Piers Cawley wrote: How would they know who to arrest if nobody turned up with the ID card within seven days? Implementation detail. Do you think that the marketroids that work for the government are any better, on the average, than the others ? Oh, and ID cards should be soft pink, too. More pleasant to the customers' eyes : so they'll accept them with more facility.
Re: Stupid fucking antivirus software
On Sun, Aug 31, 2003 at 01:24:56PM +0100, Peter Sergeant wrote: I appreciate that to some people the concept of business is a strange one - note the /. readers calling SCO stupid (while the SCO executives make a lot of money, and said readers remain second-rate programmers earning a pittance) - if there's little demand for a feature in a The SCO executives may be stupid. Time will tell if they end up in jail for ramping their stock, or taken to the cleaners by shareholder class action following a stock price collapse on losing the case. Or they may be smart. Either way, they don't seem to be trying to make their money this time by selling a product or a service to their customers (existing or new). product, then the company would be stupid to develop it. Which suggests that one approach would be to create such demand. Or at least the appearance of such demand. Maybe we should all start making requests to sales departments: Hi, I was evaluating AV products for purchase. I notice that while many are capable of warnings the senders of infected e-mail, it seems that some are unable to distinguish viruses that fake the sender address, and so send out warnings to innocent third parties. I don't want to be the victim of a defamation case from such a third party, so can you assure me that your product can distinguish such viruses, and differentiate its actions based on the virus type? (and with the other hand type e-mail to the customer service departments of any firm that does mention its product in the report (Norton AV, you are the winner here) suggesting that because their product is positively identifying a SOBIG.F and then taking the most dumb action possible, it isn't doing much to enhance their product's technical competence to me. This is making it unlikely that I would buy such a product in the future. Every bounce is a black mark of stupidity) Hmm. I wonder if we can spread the FUD to the point of suggesting that the AV vendor might get sued for defamation. Nicholas Clark
Re: insidious biometrics, identity crises
Piers Cawley [EMAIL PROTECTED] wrote: Elaine -HFB- Ashton [EMAIL PROTECTED] writes: Tony Bowden [EMAIL PROTECTED] quoth: * *You only have to be able to produce your driving license when asked, and *you have up to 7 days to do so. You don't have to be carrying it. Well, I suspect something similar would happen with an ID card. How would they know who to arrest if nobody turned up with the ID card within seven days? Surely they'd just put up wanted posters, just like the wild west? -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: insidious biometrics, identity crises
On Mon, 1 Sep 2003, Piers Cawley wrote: *You only have to be able to produce your driving license when asked, and *you have up to 7 days to do so. You don't have to be carrying it. Well, I suspect something similar would happen with an ID card. How would they know who to arrest if nobody turned up with the ID card within seven days? Given that the proposals call for biometric data to be stored on the card and in the system I assume that once cards are compulsory (probably even before then) the police will have powers to take a biometric sample from anyone they stop as a matter of course. Then they'd just look up the matching record(s) and thus know who to arrest for not showing up. Organised criminals would just forge ID cards as necessary and always carry them thus satisfying the cursory checks likely to be carried out in any situation where the person stopped is not arrested on the spot. Jason Clifford -- UKFSN.ORG Finance Free Software while you surf the 'net http://www.ukfsn.org/ ADSL Broadband available now
Re: insidious biometrics, identity crises
On 1 Sep 2003 at 9:56, Rafael Garcia-Suarez wrote: Philip Newton wrote: On 29 Aug 2003 at 22:29, Piers Cawley wrote: Michael Stevens [EMAIL PROTECTED] writes: Aah, but what programming language would be best for them to use on such a project? Befunge. Or Brainfuck. Maybe INTERCAL. Malbolge. The obligatory dantesque reference ? No, the obligatory language that's very easy to program in, hence suited for large projects. http://www.google.com/search?q=malbolgebtnI=I%27m+Feeling+Lucky Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: Stupid fucking antivirus software
At 09:35 01/09/03, Nicholas Clark wrote: Hmm. I wonder if we can spread the FUD to the point of suggesting that the AV vendor might get sued for defamation. Try it - and maybe we can get it slashdotted. Alex Available for java/perl/C++/web development in London, UK or nearby. Apache FOP, Cocoon, Turbine, Struts,XSL:FO, XML, Tomcat, JSP http://www.OWAL.co.uk/
Re: insidious biometrics, identity crises
On Mon, 1 Sep 2003, Tim Sweetman wrote: Piers Cawley wrote: Befunge. Or Brainfuck. Maybe INTERCAL. It appears to be a natural law that london.pm discussions evolve until they are discussing Befunge or Brainfuck, then disintegrate. Befunge and Brainfuck: the Nazis of the Computing World Maybe we ought to have a programming language called Hitler just for the purpose. Indeed the the module Acme::Hitler would be ideal for bringing the endless bleating on clpm about why people recommend using modules to a timely end. /J\
Re: mod_gzip and mod_perl
Alex McLintock [EMAIL PROTECTED] wrote: A slightly different question to the one Simon just asked but does anyone use mod_gzip with mod_perl? I found that they interfered with each other so in the end I disabled mod_gzip on mod_perl generated pages. I haven't looked at this in about a year so maybe my modules are out of date If you're using apache 1.x, then you need to use a perl module like Apache::DynaGzip. You're right about not being able to use mod_gzip. If you're using apache 2, then mod_deflate works as a new output filter so should be applicable to all types of content. -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: insidious biometrics, identity crises
Elaine -HFB- Ashton [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] quoth: * *How would they know who to arrest if nobody turned up with the ID *card within seven days? Well, the car has a vin and registration. I'm sure that taking the car in lieu of identification would likely produce a license. Not if they stop you walking down the street.
Re: Getting a Hashkey for a Perl Data Structure
On Sun, Aug 31, 2003 at 12:15:13PM +0100, Sam Vilain wrote: On Sat, 30 Aug 2003 16:08, Nicholas Clark wrote; NC Okay, so is there a module that will produce an identical NC serilisation of data structures for all versions of perl? As NC you also want for all versions of the module I think you're asking for the module author to perform an impossible request, to substitute for a lack of correct system testing on the part of the user. Be careful with your citations and attributions please. It's not clear from your reply that I'm *not* the one asking that. I was merely noting that Mark's summary sentence missed out one requirement made clear in the details later on. I never stated my own opinion, which is (and was at the time of writing) was that it is unlikely that any serialisation module can actually guarantee this. (It may try, but some unforseen future event/bug discovery make break such a guarantee). Hence the only way to be sure is to ascertain which parts of your data are important to your uniqueness constraint, serialise those parts yourself, and use that as your future proof immutable comparison system. I believe that that way you are safe against all external bugs and feature enhancements. For internal bugs and feature enhancements, well, you know who to blame. :-) Nicholas Clark
Re: Bug in perl?
On Fri, Aug 29, 2003 at 12:14:05AM +0100, Sam Vilain wrote: Devel::Peek and Scalar::Util are your friends debugging these sorts of problems. Perhaps changing it to something like: As is Devel::DumpStack, which showed me that the weirdness I thought I was getting was in fact due to me being an idiot and poking my code in the wrong place, and hence sometimes hiding the error. The moral of the story is Heisenbugs are your fault. Don't blame perl. -- David Cantrell | Reprobate | http://www.cantrell.org.uk/david It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it -- Alan Cooper
Re: gzipping your websites
On 1 Sep 2003 at 15:26, Jason Clifford wrote: On Mon, 1 Sep 2003, David Cantrell wrote: I don't do the uncompression on the fly, but do people think it's reasonable for me to have bzipped files on my site? Obviously, people using sane systems can deal with them, but I have no idea whether those stuck in the Microsoftian Dark Ages can. In fact, can they easily deal with gzips? gzip is not a problem for modern clients as all browsers support it. So this is not a problem for browser-ish content such as HTML. However, if you offer files for download that are gzipped, then you may run into either of the following problems: (a) the browser ungzips them during the download but doesn't strip the .gz suffix, leading to confusion (b) the browser doesn't ungzip them and the user cannot do so themselves. WinZip can handle .gz and is probably widely available (I'll wager it's one of the most common non-registered shareware programs) but you can't really rely on it. I don't think that is the case with bzip though. Ditto. I haven't heard of a browser that can handle bzip2 (though I imagine Mozilla can do it if built with -DKITCHEN_SINK), and most windows users will not have bunzip2 on their systems. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: gzipping your websites
Philip Newton [EMAIL PROTECTED] wrote: Of course, this only really works well for static content. Static Content is a Good Thing[tm]. You should try to have as much of it as possible. The you can let Apache do the hard work of implementing HTTP correctly (caching, byte ranges, etc). Agreed. And it would be even better if all the content was pre-compressed (e.g., with a cron job: gzip -9 *) rather than doing it on the fly. I tried using Apache MultiViews to served pre-compressed static content, but to no avail. The idea was Apache would map a request for index.html to index.html.gz and serve the precompressed file instead. In the same way that language encoded files are mapped: index.html - index.html.jp . Has anyone managed to get content negotiation to work for pre-compressed static content? ... this is the ideal scenario speed-wise. Nige -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: gzipping your websites
Philip Newton wrote: I don't think that is the case with bzip though. Ditto. I haven't heard of a browser that can handle bzip2 (though I imagine Mozilla can do it if built with -DKITCHEN_SINK), and most windows users will not have bunzip2 on their systems. Konqueror has been able to handle bzip for quite a while, provided naturally that the content is sent with the correct headers. I am not aware of other browsers having similar functionality. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: gzipping your websites
On Mon, Sep 01, 2003 at 03:26:36PM +0100, Jason Clifford wrote: On Mon, 1 Sep 2003, David Cantrell wrote: I don't do the uncompression on the fly, but do people think it's reasonable for me to have bzipped files on my site? Obviously, people using sane systems can deal with them, but I have no idea whether those stuck in the Microsoftian Dark Ages can. In fact, can they easily deal with gzips? gzip is not a problem for modern clients as all browsers support it. I don't think that is the case with bzip though. Oh I don't care if the browser doesn't support it, just whether there is common Doze software to uncompress it later like there is for tarballs. The data I've compressed with bzip2 is Palmdoc databases, and so not something the user would particularly want to see in their browser what with it being binary gibberish. -- David Cantrell | http://www.cantrell.org.uk/david Page 32, line 1: leave out genitals and insert penis -- proposed amendment to the Sexual Offences Bill
Re: gzipping your websites
At 10:31 -0500 9/1/03, Nigel Hamilton wrote: Philip Newton [EMAIL PROTECTED] wrote: Static Content is a Good Thing[tm]. You should try to have as much of it as possible. The you can let Apache do the hard work of implementing HTTP correctly (caching, byte ranges, etc). Has anyone managed to get content negotiation to work for pre-compressed static content? ... this is the ideal scenario speed-wise. Er... I may be missing something, but isn't this as easy as checking the Accept-Encoding input header, and if properly set, redirect internally to the gzipped file and set the output header Encoding ? Liz
Re: gzipping your websites
Nigel Hamilton [EMAIL PROTECTED] wrote: I tried using Apache MultiViews to served pre-compressed static content, but to no avail. The idea was Apache would map a request for index.html to index.html.gz and serve the precompressed file instead. In the same way that language encoded files are mapped: index.html - index.html.jp . Has anyone managed to get content negotiation to work for pre-compressed static content? ... this is the ideal scenario speed-wise. I think that mod_gzip should detect this situation and do the right thing. I'm guessing that mod_gzip_can_negotiate and mod_gzip_static_suffix are the options you want. http://www.schroepl.net/projekte/mod_gzip/config.htm As for mod_deflate, it looks like it doesn't do this. http://httpd.apache.org/docs-2.0/mod/mod_deflate.html -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: gzipping your websites
On 1 Sep 2003 at 10:31, Nigel Hamilton wrote: I tried using Apache MultiViews to served pre-compressed static content, but to no avail. The idea was Apache would map a request for index.html to index.html.gz and serve the precompressed file instead. In the same way that language encoded files are mapped: index.html - index.html.jp . Has anyone managed to get content negotiation to work for pre-compressed static content? ... this is the ideal scenario speed-wise. I've managed to have a file foo.html.gz and have Apache serve that on a request for foo.html. I did not, however, have a file foo.html in the same directory, so content negotiation wasn't really involved, or not in the way that I understand you are after. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: gzipping your websites WINRAR 40 days trial
I used to be annoyed when someone zipped and the rared. Winzip cannot even handle this yet. Nowadays I can just say that RAR is more universial the Zip. Marcus Original Message: - From: Chris Devers [EMAIL PROTECTED] Date: Mon, 1 Sep 2003 12:35:45 -0400 (EDT) To: [EMAIL PROTECTED] Subject: Re: gzipping your websites On Mon, 1 Sep 2003, David Cantrell wrote: Oh I don't care if the browser doesn't support it, just whether there is common Doze software to uncompress it later like there is for tarballs. Well, everyone using Windows is likely to be using either a copy of WinZip (unpaid for, of course) or if they're using XP the system has *finally* added capabilities for dealing with compressed formats. Poking around WinZip's site, I can't find any mention of bzip / bzip2. asking Google about winzip bzip2 turns up phrases such as Unfortunately WinZip does not unzip bzip2 [trolltech.com] Of course, some day WinZip will add bzip2 [redhat.com] etc. The most fruitful links seem to point to Cygwin, which while appreciated is about as likely as saying just install Linux. Actually, that pretty much *is* what they're saying... :) Searching for windows xp bzip2 turns up a link for PowerArchiver, which while apparently nicer than WinZip, isn't a program that most people seem to be running (or, arguably, will ever see a need for, as long as WinZip does .zip and .zip is all they're interested in). A poke around MS's techpubs site suggests that Win-Me-Oh-God-NO was the first version to support the .zip format natively (that only took them 15 years -- impressive), but apparently it's the only compression format that MS has any interest in. I see no mention of bzip, gzip, sit, hqx, etc. So... no, bzip file support is unlikely unless they're savvy enough to have installed Cygwin, PowerArchiver, or similar tools. Which most Windows users probably haven't probably never will. Their loss. -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/blog/ massively parallel, adj. 1 Hypergeometry (Of two right lines) nonintersecting and many megaparsecs apart even at the point at infinity. 2 (Of a computer architecture) employing 2^N microprocessors where N depends on Intel's current discount structure; esp. of a system massively searching for parallel advances in the programming arts. Compare MASSIVELY SERIAL. -- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995 mail2web - Check your email from the web at http://mail2web.com/ .
Re: JOB: PHP and Perl Coder Vacancy
On Mon, Sep 01, 2003 at 06:08:20PM +0100, I forwarded:
Email me for more.
Peter
The same bloke posted this to another list:
My programming team in based in central London. The team comprises of
members of varying skills and abilities. We build websites using PHP and
PERL running on Linux servers. We are working towards adopting an XP
methodology.
In order to develop the team, we are looking for skilled people to visit
our offices and teach us about stuff. Techniques, technologies, things we
need to know that will make us better at what we do.
I'm looking for companies or individuals who can provide quality training
services.
Who knows what I could do ?
--
# Earle Martin http://c2.com/cgi/wiki?EarleMartin
$a=f695a9a2176a7dd1618af6649896ee10f05ea986de18af6277e9a1d8ef4696644569a1d.
8ef46961ae1e64277e9896eea7d92ea8003e9a1d8ef4696f6950;$b=8ALB6AIA4.BA2;$c=
join,unpackC*,$b;$c=~s/7/2/g;@b=split,$c;foreach$d(@b){$e=hex(substr($a
,$f,$d));while(length($e)8){substr($e,0,0)=0;}print packb8,$e;$f+=$d;}
Re: compression (was: gzipping your websites)
On 01/09/2003 at 12:35 -0400, Chris Devers wrote: Unfortunately WinZip does not unzip bzip2 [trolltech.com] bzip2 is much, much slower than gzip, but doesn't provide significantly smaller files, at least according to some benchmarks on Jeremy Zawodny's site: http://jeremy.zawodny.com/blog/archives/000953.html So, apart from geeky dickwaving (I use bzip2 not gzip, because all my cool Linux pals told me it was better), why use it at all? Mind you, given PKZip and Winzip are currently touting incompatible versions of encryption with Zip archives, distinguished by the different extensions .zip and, er, .zip, maybe everyone should use .gz instead. Hmm, or maybe .sit files. Hem. -- :: paul :: compiles with canadian cs1471 protocol
Re: compression (was: gzipping your websites)
On Mon, Sep 01, 2003 at 08:20:32PM +0100, Paul Mison wrote: How often do you *serve* log files? Wasn't the discussion up until now about gzip for web server downloads? How often do you serve a MySQL file that's 2.5GB uncompressed? Is this typical of most web applications? If not, why bring in that particular benchmark in the first place? Roger
Re: insidious biometrics, identity crises
Greg McCarroll [EMAIL PROTECTED] quoth: * *bah, call them guns - you want to try Northern Ireland you do, *where in the its hay day, the RUC carried sub machine guns and *were generally escorted by army with fully automatic rifles and *a penchant for tracking you in the scopes despite what the regs *might have said, It's not the size that counts :) e.
Re: insidious biometrics, identity crises
On Mon, 1 Sep 2003, Piers Cawley wrote: Cop with gun: Show me your ID, sir! Me: I'm terribly sorry, I don't have my wallet about my person. CwG: Okay, what's you're name and address? Me: Albert Urquhart of 72, Regent Square, Doncaster. CwG: Postcode? Me: Um... I've just moved in, terribly sorry I can't remember it. CwG: Right, you have seven days to produce your ID card at any police station -- here's the appropriate bit of paper to bring along with it. Me: Right ho. Have a nice day. If they require my DNA they are going to have to arrest me to get it. Refusing to provide it will probably be made an offence and you could then find yourself sharing a cell with Big Ron. Jason Clifford -- UKFSN.ORG Finance Free Software while you surf the 'net http://www.ukfsn.org/ ADSL Broadband available now UKPOST.COM get your @ukpost.com address now... http://www.ukpost.com/ professional hosting/ADSL Broadband
Re: compression (was: gzipping your websites)
On Mon, 1 Sep 2003, Paul Mison wrote: On 01/09/2003 at 14:42 -0400, Chris Devers wrote: But at my last job, when compressing daily server logs, bzip was able to produce compressed files half to quarter the size of what gzip could do with the same log files. Consistently, over the course of months. How often do you *serve* log files? Wasn't the discussion up until now about gzip for web server downloads? No, it wasn't. At least, this sub-thread wasn't. Evildave was asking about Windows support for bzip compressed files that he would like to distribute on his site. On the fly decompression of the files was not part of the equation, as a later post by him clarified. read first, troll later? :) The point wasn't to compress as fast as possible, but to keep the size of the archive directory as small as possible. For downloads, yes, smaller files come down well, but if they take much longer to compress, your combined download+unzip time will be greater than the (admittedly slower) download+unzip time for bzip2. Horses for courses. For archived logs, they may never end up getting decompressed again, but there is a need to have the data available in case a need emerges. In this context, bzip is a better solution. For a situation where the file is decompressed often, the decompression time required by bzip becomes an issue, but that wasn't the scenario that I was describing. You asked why anyone would ever use bzip. I was giving a perfectly valid example. You're now asking about other situations. I think you're deftly evading the point :) End of discussion. Oh, is it? Okay then, can we at least have end of trolling? Pretty please? *sigh* indeed -- Chris Devers[EMAIL PROTECTED]
Re: insidious biometrics, identity crises
Piers Cawley [EMAIL PROTECTED] quoth: * *CwG: Right, you have seven days to produce your ID card at any police *station -- here's the appropriate bit of paper to bring along with it. *Me: Right ho. Have a nice day. I don't know that you could get away with that in the US as they'd track down the owner of the car after 7 days and you'd be in a lot more trouble than if you'd have just been honest. Also, most places do issue a fine which, if you can be bothered to go to court, you can usually have waived for the first offense. If you walk off from the car without responding to them at all, depending on if you get Barney Fife or not, you'd likely get some sort of hostile reaction. Of course, if you get pulled over by troopers who radio your dad instead of giving you a ticket, you start to wish for the blessed anonymity of a plastic ID. *If they require my DNA they are going to have to arrest me to get *it. They're already requiring biometrics which may include DNA for your passport so you may have to face this at some point. e.
Re: compression (was: gzipping your websites)
On 01/09/2003 at 20:26 +0100, Roger Burton West wrote: How often do you serve a MySQL file that's 2.5GB uncompressed? Is this typical of most web applications? If not, why bring in that particular benchmark in the first place? It was a page I'd seen recently and I thought that the information it included, despite being (admittedly) not tightly focussed on the exact area under discussion, was interesting, and because conversations on a number of IRC channels (including #london.pm, where someone else agreed that bzip2 was 'overrated', and #2lmc, who dissected it in typical abrasive style [0]). I lack the time or inclination to perform rigorous benchmarks on serving gzip against uncompressed files, let alone trying bzip2 or anything so rampantly unsupported. However, here's some rampantly unfair tests on a text file: [EMAIL PROTECTED]:~$ time gzip File-Type.html real0m0.557s user0m0.010s sys 0m0.010s [EMAIL PROTECTED]:~$ time bzip2 File-Type.html real0m0.033s user0m0.010s sys 0m0.020s [EMAIL PROTECTED]:~$ ls -l File-Type.html* -rw-r--r--1 blech 3631 Sep 1 20:51 File-Type.html -rw-r--r--1 blech 1370 Sep 1 20:49 File-Type.html.gz -rw-r--r--1 blech 1449 Sep 1 20:49 File-Type.html.bz2 I maintain that David is being pointlessly discriminatory in his approach, and that bzip2 has a bogus level of popularity that its merits don't justify. [0] http://2lmc.org/spool/id/3356 -- :: paul :: compiles with canadian cs1471 protocol
Re: compression (was: gzipping your websites)
On Mon, 1 Sep 2003, Paul Mison wrote: I maintain that David is being pointlessly discriminatory in his approach, and that bzip2 has a bogus level of popularity that its merits don't justify. And I maintain that you're ignoring the possibility that in certain contexts, bzip can be the appropriate tool to use. As you're clearly aware, gzip has a speed advantage over bzip. You then take this to mean that gzip is the only option consider. I find that questionable. Given a selection of tools and a set of requirements, shouldn't it always be the case that you choose which tool to use based on which one offers the best tradeoffs between features that you need and drawbacks that you can put up with? This is not a case where one tool is unambiguously better, so asserting that one should never be used seems very odd to me. -- Chris Devers[EMAIL PROTECTED] source code, n. The version of a program to which the compiler OBJECTs. See also DECOMPILING, JAMES JOYCE'S LAW OF. -- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995
Re: compression (was: gzipping your websites)
On Mon, Sep 01, 2003 at 07:13:47PM +0100, Paul Mison wrote: bzip2 is much, much slower than gzip, but doesn't provide significantly smaller files I've heard this argument before. I agree with the point, but bzip2 works well for some current problems: we've already heard about compressing Web server log files[0]. Also, if space is at a premium, bzip2 (obviously) helps. Imagine you want to distribute lots of software on CD/DVD, with the assumption that users don't want to change disks. This is part of the reason why FreeBSD packages use bzip2. Also, I suspect the case for bzip2 becomes stronger in the future. Assume Moore's Law continues to hold for CPU speed increase. Disk and memory capabilities increase faster, so none of these things matter as much as now. Bandwidth increases less rapidly than other factors[1], so for downloading files over the Internet, size becomes relatively more important. Tom [0] I remember when I used to call to call these Web logs, but that means something else nowadays. [1] I don't always agree with Jakob Nielsen, but he's been more accurate than many in this respect: http://www.useit.com/alertbox/980405.html
Re: insidious biometrics, identity crises
On Mon, 1 Sep 2003, Jason Clifford wrote: On Mon, 1 Sep 2003, Piers Cawley wrote: [ converses politely with mr policeman ] If they require my DNA they are going to have to arrest me to get it. Refusing to provide it will probably be made an offence and you could then find yourself sharing a cell with Big Ron. I heard they were telling Big Ron to behave, and threatening that if he didn't, he might end up in a cell with piers. the hatter
Re: gzipping your websites
Philip Newton wrote: On 1 Sep 2003 at 12:40, Simon Wistow wrote: Now, gzipping your outgoing webpages is a good thing cos it cuts down on transmission time and reduces your bandwidth costs. Unfortunately it's also fairly processor intensive. Which is why I heard that it's better to compress your content ahead of them and then *uncompress* it on the fly if the client says it can't read gzip content-transfer-encoding(?). *throws potential spanner* Does all this negotiation run into hot water with legacy p(r)oxy caches? Cheers ti'
Factory Classes
[ apologies for all the Perl postings today - can you tell that Buffy's over ] You may have seen my module Audiofile::Info (http://search.cpan.org/dist/AudioFile-Info/) it's a simplified interface to reading the track info from MP3 and Ogg Vorbis files. Basically, it's a factory class, you pass the constructor a filename and it returns you an Audiofile::Info::MP3 or Audiofile::Info::Ogg object as appropriate. Under the covers it uses MP3::ID3Lib or Ogg::Vorbis::Headers to do the real work. A few people have said what a good idea it is and have suggested improvements. One of the most common suggestions is why not use My::Favourite::MP3::Module instead? Being an obliging sort of chap I'd like to accommodate these requests, but obviously the best way to do this is to make it configurable and let people choose which modules to use (probably defaulting to pure Perl versions). I've done something similar before with Symbol::Approx::Sub, but I'm not sure that the interface I designed there was as useful as it could be, so I'm open to suggestions. What would be really good would be if we could autodetect which modules they had installed during installation and choose the local default from those - but I may leve that for a later release. Cheers, Dave... -- http://www.dave.org.uk Let me see you make decisions, without your television - Depeche Mode (Stripped)
Programming Email Filters
Like (I guess) many people round here I'm getting Too Much Email that I don't want to read. So I'm doing something about it. Using Perl. And no, of course, no-one elses solution will work just how I want it to work so I'm in full wheel-reinvention mode. The biggest problem I'm currently having is bounces from spam that has fake addresses in my domains as the 'From:' header, so that's the problem I'm addressing first. I have a finite number of email addresses that I want to read email for and any email addressed to a different address will be filtered off to a different folder for later investigation. I hacked up something that identified the emails I want to filter using Email::Simple, but I'd appreciate some input on what I've done. There are three areas I need help on. Problem the first. The first problem is identifying why the email ended up in my inbox. I need to work out which of the many email addresses in the many headers is aimed at me. Here's the algorithm I'm using. 1/ If there's an 'Envelope-to' header then use that and stop looking. 2/ Otherwise look for email in 'To' and 'Cc'. If something likely is fond then stop looking. 3/ Otherwise start poking around in the 'Received' headers. Can anyone see a problem with that? Problem the second. I'm using the Email::* modules but there doesn't seem to be a way to extract the actual deliverable email address from the headers. For example, from Dave Cross [EMAIL PROTECTED] I need [EMAIL PROTECTED] Currently I'm using a nasty regex hack. Bear in mind tha some nasty email clients do stupid things like [EMAIL PROTECTED] [EMAIL PROTECTED] or even '[EMAIL PROTECTED]' [EMAIL PROTECTED] Email parsing is listed as for a future release in Regexp::Common. I could use Mail::Address, but I don't really want to install Mail-Tools given that Email::* replaces most of it. Any other suggestions? Should I just write Email::Address and submit it to the Email::* project? Problem the third. I use procmail for my mail filtering, so I need to plug this new filter in with that. The processing I need is: if email is to a dodgy address then save it in 'notme' mailbox else continue with normal procmail processing end But my procmail powers are weak and I can't work out how to do it. I see that spamassassin adds a new header to the email and my next procmail rules does the filtering. That would be an acceptable solution if I can't do it all in one rule. Any help and advice on all of these issues much appreciated. Dave... -- http://www.dave.org.uk Let me see you make decisions, without your television - Depeche Mode (Stripped)
Re: compression
Tom Hukins wrote: [...] Also, I suspect the case for bzip2 becomes stronger in the future. Assume Moore's Law continues to hold for CPU speed increase. Disk and memory capabilities increase faster, so none of these things matter as much as now. Bandwidth increases less rapidly than other factors[1], so for downloading files over the Internet, size becomes relatively more important. I've seen this happening already. I've been compressing Sybase dumps for a few years now with bzip2. It takes a 2.2Gb file down to around 180Mb, whereas gzip used to get it down to about 800Mb. On older hardware, bzip will sit on the die and the run queue will float up to 1.0 until it finishes. With a 2.8GHz (give or take a few 100MHz) P-4, a bzip2 process will push the load only as far as 0.6. It's waiting for the bus or something. In any event, the process is no longer CPU-bound (something which amazed me the first time I saw it -- for once a so-called faster CPU really was faster). I think the problem with HTML files is the sizes are too small for bzip2's benefits to start kicking in. David
Re: Programming Email Filters
On Mon, Sep 01, 2003 at 02:09:58PM -0700, Dave Cross wrote: Problem the third. I use procmail for my mail filtering, so I need to plug this new filter in with that. The processing I need is: if email is to a dodgy address then save it in 'notme' mailbox else continue with normal procmail processing end But my procmail powers are weak and I can't work out how to do it. I see that spamassassin adds a new header to the email and my next procmail rules does the filtering. That would be an acceptable solution if I can't do it all in one rule. It's not the answer you want, because it doesn't use an external filter, but I use something like this, which seems to be doing a reasonable job: :0 * !^TO_\(x|y|z)@pjcj\.net notme Where x, y and z are the addresses on which I expect to receive valid mail. The major problem now is remembering all the adresses on which I expect to receive valid mail. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Programming Email Filters
On Mon, 1 Sep 2003, Dave Cross wrote:
The biggest problem I'm currently having is bounces from spam
that has fake addresses in my domains as the 'From:' header,
so that's the problem I'm addressing first. I have a finite number
of email addresses that I want to read email for and any email
addressed to a different address will be filtered off to a different
folder for later investigation.
I take a slightly different approach, which works and has as yet given 0
false positives. I use spamassassin.
1. Give mailer daemon bounces positive scores +0.5
2. Give a positive score to anything not to your primary address +0.5
3. Identify the headers that remote MTAs add to incoming spam that got
bounced. Score this relatively high. 1.50
4. Add a few rules to user_prefs for the really persistent people.
5. Make the body_8bit stuff score REALLY high 4.00 (most mailer daemon
bonuce spam is Russian)
If you want this SA config, just ask.
Now, we use procmail.
# Filter through sa.
:0fw
|/usr/local/perl580/bin/spamassassin
# For all spam
:0
* ^X-Spam-Status: Yes
{
# Filter out all the delivery failures from spoofed spam.
:0
* ^Subject:.*Returned
/dev/null
:0
* ^Subject:.*deliver
/dev/null
:0
* ^Subject:.*failure
/dev/null
# By now we've trapped 98% of the spam bounces, and we're left
# with a few.
:0:
spam
}
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: Factory Classes
On Mon, 2003-09-01 at 22:09, Dave Cross wrote: [ apologies for all the Perl postings today - can you tell that Buffy's over ] Just for the record... Out of 86 messages so far today, 12 mention perl explicitly and 3 of those probably shouldn't count... That is, of course, still way too many mentions and we should all try much harder... Dirk -- Please Note: Some Quantum Physics Theories Suggest That When the Consumer Is Not Directly Observing This Product, It May Cease to Exist or Will Exist Only in a Vague and Undetermined State.
