"High level languages have the advantage that "....
Agreed entirely. The language exists at a given level of "highness" or otherwise.
I like to take assembler, C and Haskell as 3 handy options, for example. You can write something fairly funky like:
unwords (filter ((>3).length) (words "a short string or something")
and it'll return a string comprising all those words that were >3 characters long in the original, when split on whitespace. ("short string something", duh.)
You can also write some functions to produce this same expression in C, or in assembler. But you won't, because you know the scope for lots of trivial errors with lower-level *sub*-problems is so much greater for doing so. And when you get those wrong, you'll risk having a segfault on your paws.
There are 1.5 lessons to note from this: choose a language of appropriate level to what you're trying to do. Second, prepare to scale languages on top of each other pyramid-style, so that (taking the Gimp as an example) you write your low-level speed-critical functions in C, and then expose them as functions in a scheme for combination in more powerful, functional, ways. Point is, you're building up such that things that need to run fast will do, and you get to throw around weighty concepts yourself in only a few lines of code. In the process, all I'm assuming is that the language implementation has no bugs - either the way haskell or scheme are written (normally "in themselves", with a small C stub to get you to bootstrap), and in the way the C compiler is written, and in the way the CPU handles the assembler - well, machine-code - it's presented with.
I'm also wondering, if performance is related to lowness of language level, is security related to the difference in "level" between what you're writing and what you're writing in? It's definitely related to the number of LoC required to achieve the goal - you could say that my "implementation" above is secure because it's a simple combination of high-order list functions, or because it is only 1 short LoC and therefore easily proven correct in terms of the expectations it puts on its sub-expressions; you can also see that if I'd rewritten the equivalent expression as a set of C functions, there would be much greater scope for insecurities to creep in.
"slow (forking a separate Perl process for every mail)"
Sure? Were you using the spamc/d client-server approach to it?
We're doing that here at ork on a 700MHz Duron I completed setting-up last week; it's been pushing >3000 mail/day with a rough average load increase of about 0.1 for its trouble, quite happily.
Otherwise, I agree entirely about the Bayesian filtering btw: I'm on _bogofilter_ for any mail that gets past the `usenet@' blocks, and I'm well happy with it. Very few FPs or FNs at all, and they're easy enough to fix anyway. Wahey.
While I'm passing, this "challenge-response" thing really annoys me, btw. Making all the innocent senders of mail do double the work without putting any load increase on the spammers themselves is simply unjustifiable, to my eyes. Not to mention, it's a major bloat on your mailq's resources, as well - no wonder it's nonfree. And the risk of impersonation is attrocious: I've seen these systems sending mail to half a mail2news gateway before now - talk about spreading spam!
I agree that it's about tools and libraries. And this is what I think about them, too.
At work, I brush up against XML occasionally, mostly for documentation or data-resultset purposes. In my own time, I use it in my photo gallery - result-sets from database queries get converted to XML and then spat out through XSLT in Sablotron, straight to web. For all the hoops it goes through, it's actually still quite nippy.
However, I also dislike it intensly.
I've written a blog-like system-news announcement board using a Ruby CGI against postgresql as a backend. I can pull back a result-set - a simple table-thing with each row being a text announcment, half a dozen fields (when posted, by whom, etc). And I wanted to output this in HTML form for the web, in plain-text to send to a user who wanted it via email every day, and in s-exp form for my own gratification. However, the first problem you run into is the formatting. A textarea in an HTML form gives no line-wrapping (wanted for plaintext output, but only in specific fields) and embeds ^M characters everywhere. When the output is HTML, those ^Ms want to become br tags. When the output is plaintext or sexp, they want to become \n. Simple, if ONLY there were a way of doing either elementary reformatting or search-n-replace in XSLT. There is, but s/// is about 10 lines' worth, if my googling is to be believed. That makes it non-optimal for one of its primary uses: making transformations on big blocks of text-based data, and it can't even edit within a node correctly? Pathetic. Why shouldn't I just write 3 output methods in my Ruby CGI script that take the result-set directly to text, HTML or sexp formats, with the power of ruby to do a #gsub("^M", "\n") on just the fields I want, in a tiny few extra characters of code?
Now to tackle what you've said:
"Using Perl regexps to parse XML is silly"
No, it's not. Perl regexps are a highly featureful, pre-existing, code. I'd be surprised if libxml *didn't* use regexps in its XML parsers, frankly.
"e.g. attributes in any order, elements covering multiple lines) that regexps aren't good at handling."
These things are not a problem. You can easily match an attribute occurring, as it does, within a n opening-tag, and pull out both the name and the contents. Using that to set a variable of given name in your program - a highly important part, given that XML is a data-transfer format and it's the internal representation afterwards that is its whole raison-d'etre - is trivial. Thus, perl wins. Multi-line matching is explicitly catered-for in perl, with/m or/s on the end of the regexp.
"There's a number of tools and libraries "...
Indeed there are. And you know what? When I've got a small paragraph (under 10 lines) of data that I want to transfer from A to B, the last thing I'm going to do is invoke a 600Kb library so I can use a pompous and fashionable set of functions to produce "XML", when perl/ruby/sh have all had perfectly valid "print" or "echo" commands for the past decade or more. If the output is valid XML, you've no reason to diss the method used to produce it.
As a final example, I've also had a few documents to be writing, of my own, at work. I've had two options: either sit down, set up emacs to handle XML sources smoothly so I can open and close tags at the push of a key-chord the way I *want* to create the stuff, or program a small sub-language. Lisp, in the form of _librep_, won the day, with a few small functions to produce strings based on the input. And guess what? Because this is a programming language rather than a mere text-transforming language, I made a CGI out of it, and can embed programs within my "data", too, without feeling the urge to write to the W3C about it. Editing it is an absolute dream - opening and closing paragraphs of text is a piece of cake and fits the way I want to work. (Maybe you like looking at spikey angle-bracket characters, I dunno.) In short, "programmed text" won the day for me.
I agree that it's about tools and libraries. And this is what I think about them, too.
At work, I brush up against XML occasionally, mostly for documentation or data-resultset purposes. In my own time, I use it in my photo gallery - result-sets from database queries get converted to XML and then spat out through XSLT in Sablotron, straight to web. For all the hoops it goes through, it's actually still quite nippy.
However, I also dislike it intensly.
I've written a blog-like system-news announcement board using a Ruby CGI against postgresql as a backend. I can pull back a result-set - a simple table-thing with each row being a text announcment, half a dozen fields (when posted, by whom, etc). And I wanted to output this in HTML form for the web, in plain-text to send to a user who wanted it via email every day, and in s-exp form for my own gratification. However, the first problem you run into is the formatting. A textarea in an HTML form gives no line-wrapping (wanted for plaintext output, but only in specific fields) and embeds ^M characters everywhere. When the output is HTML, those ^Ms want to become br tags. When the output is plaintext or sexp, they want to become \n. Simple, if ONLY there were a way of doing either elementary reformatting or search-n-replace in XSLT. There is, but s/// is about 10 lines' worth, if my googling is to be believed. That makes it non-optimal for one of its primary uses: making transformations on big blocks of text-based data, and it can't even edit within a node correctly? Pathetic. Why shouldn't I just write 3 output methods in my Ruby CGI script that take the result-set directly to text, HTML or sexp formats, with the power of ruby to do a #gsub("^M", "\n") on just the fields I want, in a tiny few extra characters of code?
Now to tackle what you've said:
> Using Perl regexps to parse XML is silly
No, it's not. Perl regexps are a highly featureful, pre-existing, code.
> e.g. attributes in any order, elements covering multiple lines) that regexps aren't good at handling.
These things are not a problem. You can easily match an attribute occurring, as it does, within a n opening-tag, and pull out both the name and the contents. Using that to set a variable of given name in your program - a highly important part, given that XML is a data-transfer format and it's the internal representation afterwards that is its whole raison-d'etre - is trivial. Thus, perl wins. Multi-line matching is explicitly catered-for in perl, with/m or/s on the end of the regexp.
> There's a number of tools and libraries
Indeed there are. And you know what? When I've got a small paragraph ( characters, I dunno.) In short, "programmed text" won the day for me.
Portsentry's main failing is that it waits until a packet has got into userspace before anything happens about it, and even then it only operates on an opt-in kind of way - like you've got to be looking out for scans on specific ports, or whatever.
The alternative, and to me far more sensible, approach, is to drop all packets that aren't something you want, in a firewall, up ahead. If someone treats you to a multi-port scan, well, it appears in the logs. If someone scans you on a port on which you're listening, well, the reason you're running a front-facing service is because it's pretty well tightened instead, right?
"commercial email is not 'unsolicited' if the sender has a preexisting business or personal relationship with the sender."
Yeah. That's naff, alright. In this case, from what you say, it raises the whole question of what to do about bastards who sell your name on: you don't have any direct business relationship with them, so you can't have opted in... hmmmmm.
"but still, she was constrained to follow what they actually passed into law, not what she thought they meant."
Pretty pathetic, if you ask me. There I was, hoping judges and legal systems were designed to uphold what was *right* rather than what was *written*...
Not easily; you need to know a valid email address for them.
Of course, postmaster @ (something related to whois or reverse-DNS lookup on the incoming IP#) would be nice, but if they're evil enough to spam you, don't expect RFC-compliance:)
However, you could consider a teergrubing approach. Something like http://www.iks-jena.de/mitarb/lutz/usenet/teergrub e.en.html would be a start - or for all the difference, if you're going to mess around with the incoming SMTP stream, then why not integrate spam-checking with spamassassin (use either sendmail's milter interface or exim's exiscan, perhaps) and reject the mail as it's coming it? Then exactly the right person gets exactly the right kind of failure message.
Neither was I;) My instantaneous mileage varies wildly from 19mpg to 500-odd, depending on gear/speed/gradient and probably phase of the moon as well. However, resetting the "average mpg" as soon as I hit the M25 gives a pretty accurate view of how well I'm doing - I can watch mpg go up as revs stay below 1900, for example.
Alternatively, I'm used to spending a week driving around town and doing 4-hour motorway drives of a weekend - a pleasant Saturday afternoon outing. That would net me ~240 miles on a tank in my previous car - a Vectra, with 23/33/42mpg ratings. After last week, doing exactly that sort of thing, I got 485 miles on the tank.
"I cannot get a Toledo in the US."
Pity. I really like mine, think there should be more born every minute:)
"Your Toledo, being designed by German engineers, qualifies as German,"
Indeed it does. That's half the reason I got it - German reliability at Spanish prices, basically. All the internals look just like the equivalent parts on a VW Bora/Golf, here, down to the shape and positioning of indicator stalks.
I also considered Toyota as the token Japanese reliability option. Nothing they offer includes cruise-con until you get up to a Camry, when you're talking 2.5 or 3.0l petrol engines (yeuck!), and you can't get EBD and diesel on the same new-style Corolla, and the now-old Avensis had the wrong kind of hollow metal, and 2nd gear was way out left in most of their manual boxes... IOW they couldn't quite rival the Toledo.
"Then, how clean is Diesel around the UK?"
140 g/km, I think is the rating. It's the second to lowest tax band, anyway.
"I'm saving $2000 on a 5-year period"
I estimate that, over a 1-year period, I'm going to save about GBP700 with mine. That's council-tax to me.
"Diesel car. I can get 50mpg on highway driving at normal speed."
A Honda Civic 1.6VVTi is capable of near-enough 50mpg when driven so's to maximise use of the green `economy' light.
I've got the Seat Toledo 1.9TDi SE (so a very similar engine to your VW diesel, no doubt). The quoted mpg ratings are 45, 55, 65.7mpg. I get around 55mpg on the motorways myself, ticking along at 70-75mph (only had it a fortnight, results still pending!).
"very nice handling"
Check. I went for a spin around the back-roads in deepest darkest Surrey last night, bombing around corners at a rate of knots, with no sideways rolling/wallowing at all.
"side aribags and all kind of safety features"
Check;)
"What do you all think?"
I think I got the same performance - almost the same car - but without the VW-brand price-hike, myself;) And the power-to-weight ratio seems about right at 1.9TDi and 1.3 tonnes.
"For example, you hear of time going forward and backward, but never up down left or right."
Read _A Brief History of Time_. You'll find complex-time being posited in there, maybe 3/4 the way through or so - so left/right is very much a possibility, or at least, the "time" equivalent of such things.
Coo, while I had my suspicions, I hadn't read that in black and white before.
Doesn't surprise me, really.
For the record, the company where I work rejected Rotor out of hand as the license is just unworkable in a commercial product. Not even worth my time to try playing with it. Compare LGPL (for the libraries/classes), no problem.
No, that might be a justification for the UN to take action. It is no justification at all for the US and UK to bypass recognized procedures against the rest of the world's better judgement and instigate an aggressive attack.
"Isn't it time to get dirty and fire up the good old spy tricks again?"
If they manage to track down Bin Laden through this chap and the associated echelon wizardry, what will UK+US use as justification for going to war with Iraq?
I'm on my ~5th mobile in as many years, myself, and consider it my main voice-mode comms device.
And I tend to agree - there are those who really cheese me off by either wandering down the street yelling into their phones ("HI! HOW'RE YOU?" - to which I invariably reply `fine, you?'), or by relaying every single pause on the train to their office.
The technology exists to make mobiles quiet and unobtrusive - vibrate-then-ring on Motorolas, easy choice of different "profile"s on Nokias, various ways to filter calls (either by simply not ringing or actively filtering calls down to a select group): you name it. The problems we experience are simply due to other peoples' inconsideration and/or willful ignorance of how to operate the blighters.
Re:keybinding for tab switching in mozilla/NS7?
on
Hyatt Discusses Tabs
·
· Score: 1
Glad to oblige.
While I'm passing, have a go with some of the mozilla / phoenix extensions - Tools / Preferences / Themes and Extensions. There are a few enhancements to tabbing behaviour there - notably the abilities to move tabs around, remove tabs on the right or left of current, that sort of thing. I think one of them also introduces Ctrl+number as a way to jump to the n'th tab along as well.
"to violate fundamental principles, including the one that it's not moral to punish the innocent to get at the guilty,"
That rather depends on which version of ethics you're using at the time, doesn't it? There are considerably more valid users of usenet *outside* Telestra's borders than there are within, all of whom suffer from Telestra's bad approach to spam. Given that the whole reason for the UDP suggestion is persistent continual large-scale offence from them, it's not as though they've not had the chance to repair their ways. Cutting off a few for the sake of the greater good is very much a valid "moral" choice.
"I wouldn't punish the innocent to get Usama bin Ladin, let alone spammers."
OBL's daily activities don't impinge on you in any way, until you get an odd-one-out. Spammers' activities *do* impinge, through ISPs having to pass on bandwidth costs to someone, ie their users.
"One would think, though, that if it weren't for/. Usenet would be more popular than it is today. Usenet is pretty geeky, after all."
Hmmmm. And evolution leads to less geekiness and this is a good thing?
If the rise of web-based discussion systems means all the AOL weenies get *off* Usenet, I suppose that's a good thing. But don't say Usenet hasn't "evolved" as though it were a bad thing. After all, there's nothing to stop you setting yourself up with a perfectly decent news-reader and actually talking to people on it, even on windoze, is there?
You should look into a combination of LVM and a journalled filesystem - xfs, with jfs or reiserfs coming in second, I should recommend. Something like lvextend followed by xfs_growfs really is a delight to behold - expand the volume underneath it, tell the filesystem to re-evaluate the size of its data-part based on the size of the underlying volume - while it's still mounted. BTDT, rejoiced loudly.
As for software-RAID: please, just say no. It just sucks way too much CPU to leave your hunky server to be anything other than a dedicated file-server, and even then I'm far from convinced. If I want RAID for reliability and/or speed, I'll go hardware for that, at least.
Well, you could ask if its use is the best possible, or least-bad possible course of action in terms of consequences you know about; or you could see whether it treats people as an end in themselves rather than a means to an end. Read _Computers, Ethics and Society_ (2nd ed) for a few interesting case-studies on the matter.
"The GPL is political enough - we don't need this."
Indeed. I find the OSD's point about no discrimination to be quite enlightening: how should one apply that? If it's "discrimination" to discriminate between development of commercial or open-source software, is it not also discrimination to unlicense the software for use in certain countries?
Thinking more, this leaves only selfish interest on behalf of the US - both behind the original crypto-export restrictions, and in further use of open-source software by various countries. If you want to "win", you'll have to, and should, choose another avenue that isn't software or legality - either force or negotiated peace seem potential options to me.
And no, I refuse to use Plan9 because I disagree with the per-country restrictions on use. That download license is not Open IMO.
Yes, I also thought the remit of a programmer was to use the best language for the job - if a low-level language gives speed for an "inner loop" bit of your opplicotion, consider that optimization but if a decent high-level language provides the glue to fling these things around constructively, go for it.
I've heard the view that the Gimp might not be the nicest of graphics-editing programs, but you've still got to appreciate the combination of lots of low-level C functions for speed with the use of scheme (SIOD) on top to allow you to stick,em together.
However, that doesn't stop some people from inflicting their bad experiences with a particular language or means of development on entire departments - to the detriment and segfaults of all:(
Not only is `national' no use, but such a list would be only tempting fate - there's nothing stopping a spammer sucking a few addresses off it and misusing them, then you've still got to get off your ass and persue them.
And, of course, this is basically legal recognition that some forms of spam are acceptable - it's opt-out not opt-in.
"Why does everyone seem to think that the right to free speech covers everything a body might want to say about anything?"
Because it does - at least insofar as if you're going to abstract slightly from "one person" to "an organizational body", when you might as well also abstract slightly from "speech" to "publish content". What you don't like comes under *responsibility* attendant with the freedom of speech.
Slashdot Mirror
"High level languages have the advantage that "....
Agreed entirely. The language exists at a given level of "highness" or otherwise.
I like to take assembler, C and Haskell as 3 handy options, for example. You can write something fairly funky like:
unwords (filter ((>3).length) (words "a short string or something")
and it'll return a string comprising all those words that were >3 characters long in the original, when split on whitespace. ("short string something", duh.)
You can also write some functions to produce this same expression in C, or in assembler. But you won't, because you know the scope for lots of trivial errors with lower-level *sub*-problems is so much greater for doing so. And when you get those wrong, you'll risk having a segfault on your paws.
There are 1.5 lessons to note from this: choose a language of appropriate level to what you're trying to do. Second, prepare to scale languages on top of each other pyramid-style, so that (taking the Gimp as an example) you write your low-level speed-critical functions in C, and then expose them as functions in a scheme for combination in more powerful, functional, ways. Point is, you're building up such that things that need to run fast will do, and you get to throw around weighty concepts yourself in only a few lines of code.
In the process, all I'm assuming is that the language implementation has no bugs - either the way haskell or scheme are written (normally "in themselves", with a small C stub to get you to bootstrap), and in the way the C compiler is written, and in the way the CPU handles the assembler - well, machine-code - it's presented with.
I'm also wondering, if performance is related to lowness of language level, is security related to the difference in "level" between what you're writing and what you're writing in? It's definitely related to the number of LoC required to achieve the goal - you could say that my "implementation" above is secure because it's a simple combination of high-order list functions, or because it is only 1 short LoC and therefore easily proven correct in terms of the expectations it puts on its sub-expressions; you can also see that if I'd rewritten the equivalent expression as a set of C functions, there would be much greater scope for insecurities to creep in.
"slow (forking a separate Perl process for every mail)"
Sure? Were you using the spamc/d client-server approach to it?
We're doing that here at ork on a 700MHz Duron I completed setting-up last week; it's been pushing >3000 mail/day with a rough average load increase of about 0.1 for its trouble, quite happily.
Otherwise, I agree entirely about the Bayesian filtering btw: I'm on _bogofilter_ for any mail that gets past the `usenet@' blocks, and I'm well happy with it. Very few FPs or FNs at all, and they're easy enough to fix anyway. Wahey.
While I'm passing, this "challenge-response" thing really annoys me, btw. Making all the innocent senders of mail do double the work without putting any load increase on the spammers themselves is simply unjustifiable, to my eyes. Not to mention, it's a major bloat on your mailq's resources, as well - no wonder it's nonfree. And the risk of impersonation is attrocious: I've seen these systems sending mail to half a mail2news gateway before now - talk about spreading spam!
There are several already.
;)
The RBLs were an initial attempt to do so, but only prove about 60% accurate these days (at least from what I see - I've given up on the idea now).
Then you've got Razor2 and Pyzor, and the DCC to be investigating.
After you
I agree that it's about tools and libraries. And this is what I think about them, too.
/m or /s on the end of the regexp.
At work, I brush up against XML occasionally, mostly for documentation or data-resultset purposes. In my own time, I use it in my photo
gallery - result-sets from database queries get converted to XML and then spat out through XSLT in Sablotron, straight to web. For all the hoops it goes through, it's actually still quite nippy.
However, I also dislike it intensly.
I've written a blog-like system-news announcement board using a Ruby CGI against postgresql as a backend. I can pull back a result-set - a
simple table-thing with each row being a text announcment, half a dozen fields (when posted, by whom, etc). And I wanted to output this in HTML form for the web, in plain-text to send to a user who wanted it via email every day, and in s-exp form for my own gratification.
However, the first problem you run into is the formatting. A textarea in an HTML form gives no line-wrapping (wanted for plaintext output,
but only in specific fields) and embeds ^M characters everywhere. When the output is HTML, those ^Ms want to become br tags. When the output
is plaintext or sexp, they want to become \n. Simple, if ONLY there were a way of doing either elementary reformatting or search-n-replace in XSLT. There is, but s/// is about 10 lines' worth, if my googling is to be believed. That makes it non-optimal for one of its primary uses: making transformations on big blocks of text-based data, and it can't even edit within a node correctly? Pathetic.
Why shouldn't I just write 3 output methods in my Ruby CGI script that take the result-set directly to text, HTML or sexp formats, with the power of
ruby to do a #gsub("^M", "\n") on just the fields I want, in a tiny few extra characters of code?
Now to tackle what you've said:
"Using Perl regexps to parse XML is silly"
No, it's not. Perl regexps are a highly featureful, pre-existing, code. I'd be surprised if libxml *didn't* use regexps in its XML parsers, frankly.
"e.g. attributes in any order, elements covering multiple lines) that regexps aren't good at handling."
These things are not a problem. You can easily match an attribute occurring, as it does, within a n opening-tag, and pull out both the name and the contents. Using that to set a variable of given name in your program - a highly important part, given that XML is a data-transfer format and it's the internal representation afterwards
that is its whole raison-d'etre - is trivial. Thus, perl wins.
Multi-line matching is explicitly catered-for in perl, with
"There's a number of tools and libraries "...
Indeed there are. And you know what? When I've got a small paragraph (under 10 lines) of data that I want to transfer from A to B, the last thing I'm going to do is invoke a 600Kb library so I can use a pompous and fashionable set of functions to produce "XML", when perl/ruby/sh have all had
perfectly valid "print" or "echo" commands for the past decade or more. If the output is valid XML, you've no reason to diss the method used to produce it.
As a final example, I've also had a few documents to be writing, of my own, at work. I've had two options: either sit down, set up emacs to
handle XML sources smoothly so I can open and close tags at the push of a key-chord the way I *want* to create the stuff, or program a
small sub-language. Lisp, in the form of _librep_, won the day, with a few small functions to produce strings based on the input. And guess what? Because this is a programming language rather than a mere text-transforming language, I made a CGI out of it, and can embed programs within my "data", too, without feeling the urge to write to
the W3C about it.
Editing it is an absolute dream - opening and closing paragraphs of text is a piece of cake and fits the way I want to work. (Maybe you like looking at spikey angle-bracket characters, I
dunno.)
In short, "programmed text" won the day for me.
I agree that it's about tools and libraries. And this is what I think about them, too.
/m or /s on the end of the regexp.
At work, I brush up against XML occasionally, mostly for documentation or data-resultset purposes. In my own time, I use it in my photo gallery - result-sets from database queries get converted to XML and then spat out through XSLT in Sablotron, straight to web. For all the hoops it goes through, it's actually still quite nippy.
However, I also dislike it intensly.
I've written a blog-like system-news announcement board using a Ruby CGI against postgresql as a backend. I can pull back a result-set - a simple table-thing with each row being a text announcment, half a dozen fields (when posted, by whom, etc). And I wanted to output this in HTML form for the web, in plain-text to send to a user who wanted it via email every day, and in s-exp form for my own gratification.
However, the first problem you run into is the formatting. A textarea in an HTML form gives no line-wrapping (wanted for plaintext output, but only in specific fields) and embeds ^M characters everywhere. When the output is HTML, those ^Ms want to become br tags. When the output is plaintext or sexp, they want to become \n. Simple, if ONLY there were a way of doing either elementary reformatting or search-n-replace in XSLT. There is, but s/// is about 10 lines' worth, if my googling is to be believed. That makes it non-optimal for one of its primary uses: making transformations on big blocks of text-based data, and it can't even edit within a node correctly? Pathetic.
Why shouldn't I just write 3 output methods in my Ruby CGI script that take the result-set directly to text, HTML or sexp formats, with the power of ruby to do a #gsub("^M", "\n") on just the fields I want, in a tiny few extra characters of code?
Now to tackle what you've said:
> Using Perl regexps to parse XML is silly
No, it's not. Perl regexps are a highly featureful, pre-existing, code.
> e.g. attributes in any order, elements covering multiple lines) that regexps aren't good at handling.
These things are not a problem. You can easily match an attribute occurring, as it does, within a n opening-tag, and pull out both the name and the contents. Using that to set a variable of given name in your program - a highly important part, given that XML is a data-transfer format and it's the internal representation afterwards that is its whole raison-d'etre - is trivial. Thus, perl wins.
Multi-line matching is explicitly catered-for in perl, with
> There's a number of tools and libraries
Indeed there are. And you know what? When I've got a small paragraph ( characters, I dunno.)
In short, "programmed text" won the day for me.
Portsentry's main failing is that it waits until a packet has got into userspace before anything happens about it, and even then it only operates on an opt-in kind of way - like you've got to be looking out for scans on specific ports, or whatever.
The alternative, and to me far more sensible, approach, is to drop all packets that aren't something you want, in a firewall, up ahead. If someone treats you to a multi-port scan, well, it appears in the logs. If someone scans you on a port on which you're listening, well, the reason you're running a front-facing service is because it's pretty well tightened instead, right?
Retro-active and dicey doesn't appeal to me.
"commercial email is not 'unsolicited' if the sender has a preexisting business or personal relationship with the sender."
Yeah. That's naff, alright. In this case, from what you say, it raises the whole question of what to do about bastards who sell your name on: you don't have any direct business relationship with them, so you can't have opted in... hmmmmm.
"but still, she was constrained to follow what they actually passed into law, not what she thought they meant."
Pretty pathetic, if you ask me. There I was, hoping judges and legal systems were designed to uphold what was *right* rather than what was *written*...
Not easily; you need to know a valid email address for them.
:)
b e.en.html would be a start - or for all the difference, if you're going to mess around with the incoming SMTP stream, then why not integrate spam-checking with spamassassin (use either sendmail's milter interface or exim's exiscan, perhaps) and reject the mail as it's coming it? Then exactly the right person gets exactly the right kind of failure message.
Of course, postmaster @ (something related to whois or reverse-DNS lookup on the incoming IP#) would be nice, but if they're evil enough to spam you, don't expect RFC-compliance
However, you could consider a teergrubing approach. Something like http://www.iks-jena.de/mitarb/lutz/usenet/teergru
> I'm not talking about "instant milleage"
;) My instantaneous mileage varies wildly from 19mpg to 500-odd, depending on gear/speed/gradient and probably phase of the moon as well. However, resetting the "average mpg" as soon as I hit the M25 gives a pretty accurate view of how well I'm doing - I can watch mpg go up as revs stay below 1900, for example.
:)
:)
Neither was I
Alternatively, I'm used to spending a week driving around town and doing 4-hour motorway drives of a weekend - a pleasant Saturday afternoon outing. That would net me ~240 miles on a tank in my previous car - a Vectra, with 23/33/42mpg ratings. After last week, doing exactly that sort of thing, I got 485 miles on the tank.
"I cannot get a Toledo in the US."
Pity. I really like mine, think there should be more born every minute
"Your Toledo, being designed by German engineers, qualifies as German,"
Indeed it does. That's half the reason I got it - German reliability at Spanish prices, basically. All the internals look just like the equivalent parts on a VW Bora/Golf, here, down to the shape and positioning of indicator stalks.
I also considered Toyota as the token Japanese reliability option. Nothing they offer includes cruise-con until you get up to a Camry, when you're talking 2.5 or 3.0l petrol engines (yeuck!), and you can't get EBD and diesel on the same new-style Corolla, and the now-old Avensis had the wrong kind of hollow metal, and 2nd gear was way out left in most of their manual boxes... IOW they couldn't quite rival the Toledo.
"Then, how clean is Diesel around the UK?"
140 g/km, I think is the rating. It's the second to lowest tax band, anyway.
"I'm saving $2000 on a 5-year period"
I estimate that, over a 1-year period, I'm going to save about GBP700 with mine. That's council-tax to me.
Happiness...
"Diesel car. I can get 50mpg on highway driving at normal speed."
;)
;)
A Honda Civic 1.6VVTi is capable of near-enough 50mpg when driven so's to maximise use of the green `economy' light.
I've got the Seat Toledo 1.9TDi SE (so a very similar engine to your VW diesel, no doubt). The quoted mpg ratings are 45, 55, 65.7mpg. I get around 55mpg on the motorways myself, ticking along at 70-75mph (only had it a fortnight, results still pending!).
"very nice handling"
Check. I went for a spin around the back-roads in deepest darkest Surrey last night, bombing around corners at a rate of knots, with no sideways rolling/wallowing at all.
"side aribags and all kind of safety features"
Check
"What do you all think?"
I think I got the same performance - almost the same car - but without the VW-brand price-hike, myself
And the power-to-weight ratio seems about right at 1.9TDi and 1.3 tonnes.
"For example, you hear of time going forward and backward, but never up down left or right."
Read _A Brief History of Time_. You'll find complex-time being posited in there, maybe 3/4 the way through or so - so left/right is very much a possibility, or at least, the "time" equivalent of such things.
"Corel wrote Rotor "
Coo, while I had my suspicions, I hadn't read that in black and white before.
Doesn't surprise me, really.
For the record, the company where I work rejected Rotor out of hand as the license is just unworkable in a commercial product. Not even worth my time to try playing with it.
Compare LGPL (for the libraries/classes), no problem.
No, that might be a justification for the UN to take action. It is no justification at all for the US and UK to bypass recognized procedures against the rest of the world's better judgement and instigate an aggressive attack.
"Isn't it time to get dirty and fire up the good old spy tricks again?"
If they manage to track down Bin Laden through this chap and the associated echelon wizardry, what will UK+US use as justification for going to war with Iraq?
"The third time it was broken."
Good on ya!
I'm on my ~5th mobile in as many years, myself, and consider it my main voice-mode comms device.
And I tend to agree - there are those who really cheese me off by either wandering down the street yelling into their phones ("HI! HOW'RE YOU?" - to which I invariably reply `fine, you?'), or by relaying every single pause on the train to their office.
The technology exists to make mobiles quiet and unobtrusive - vibrate-then-ring on Motorolas, easy choice of different "profile"s on Nokias, various ways to filter calls (either by simply not ringing or actively filtering calls down to a select group): you name it. The problems we experience are simply due to other peoples' inconsideration and/or willful ignorance of how to operate the blighters.
Glad to oblige.
While I'm passing, have a go with some of the mozilla / phoenix extensions - Tools / Preferences / Themes and Extensions.
There are a few enhancements to tabbing behaviour there - notably the abilities to move tabs around, remove tabs on the right or left of current, that sort of thing. I think one of them also introduces Ctrl+number as a way to jump to the n'th tab along as well.
"Oh yeah, the inconvenience of spam is much worse than the murder of thousands of innocent civilians."
I'd like to know where you think I said anything like that.
"Please defend your "doesn't impinge" statement before the friends and family of the 3000+ people murdered in the World Trade Center attack."
I have no need to do any such thing, as you obviously didn't bother reading the bit about "daily activities" and "one-off"s.
"Next time, stop and think before you shoot off your stupid mouth."
If you lack for water with which to cool your head, try one of those things called a "toilet".
What's up with Ctrl+Pg{Up,Dn}? ;)
"to violate fundamental principles, including the one that it's not moral to punish the innocent to get at the guilty,"
That rather depends on which version of ethics you're using at the time, doesn't it? There are considerably more valid users of usenet *outside* Telestra's borders than there are within, all of whom suffer from Telestra's bad approach to spam. Given that the whole reason for the UDP suggestion is persistent continual large-scale offence from them, it's not as though they've not had the chance to repair their ways. Cutting off a few for the sake of the greater good is very much a valid "moral" choice.
"I wouldn't punish the innocent to get Usama bin Ladin, let alone spammers."
OBL's daily activities don't impinge on you in any way, until you get an odd-one-out. Spammers' activities *do* impinge, through ISPs having to pass on bandwidth costs to someone, ie their users.
"One would think, though, that if it weren't for /. Usenet would be more popular than it is today. Usenet is pretty geeky, after all."
Hmmmm. And evolution leads to less geekiness and this is a good thing?
If the rise of web-based discussion systems means all the AOL weenies get *off* Usenet, I suppose that's a good thing. But don't say Usenet hasn't "evolved" as though it were a bad thing. After all, there's nothing to stop you setting yourself up with a perfectly decent news-reader and actually talking to people on it, even on windoze, is there?
You should look into a combination of LVM and a journalled filesystem - xfs, with jfs or reiserfs coming in second, I should recommend. Something like lvextend followed by xfs_growfs really is a delight to behold - expand the volume underneath it, tell the filesystem to re-evaluate the size of its data-part based on the size of the underlying volume - while it's still mounted. BTDT, rejoiced loudly.
As for software-RAID: please, just say no. It just sucks way too much CPU to leave your hunky server to be anything other than a dedicated file-server, and even then I'm far from convinced. If I want RAID for reliability and/or speed, I'll go hardware for that, at least.
"How do I know what's a moral use of software?"
Well, you could ask if its use is the best possible, or least-bad possible course of action in terms of consequences you know about; or you could see whether it treats people as an end in themselves rather than a means to an end.
Read _Computers, Ethics and Society_ (2nd ed) for a few interesting case-studies on the matter.
"The GPL is political enough - we don't need this."
Indeed. I find the OSD's point about no discrimination to be quite enlightening: how should one apply that? If it's "discrimination" to discriminate between development of commercial or open-source software, is it not also discrimination to unlicense the software for use in certain countries?
Thinking more, this leaves only selfish interest on behalf of the US - both behind the original crypto-export restrictions, and in further use of open-source software by various countries. If you want to "win", you'll have to, and should, choose another avenue that isn't software or legality - either force or negotiated peace seem potential options to me.
And no, I refuse to use Plan9 because I disagree with the per-country restrictions on use. That download license is not Open IMO.
Yes, I also thought the remit of a programmer was to use the best language for the job - if a low-level language gives speed for an "inner loop" bit of your opplicotion, consider that optimization but if a decent high-level language provides the glue to fling these things around constructively, go for it.
,em together.
:(
I've heard the view that the Gimp might not be the nicest of graphics-editing programs, but you've still got to appreciate the combination of lots of low-level C functions for speed with the use of scheme (SIOD) on top to allow you to stick
However, that doesn't stop some people from inflicting their bad experiences with a particular language or means of development on entire departments - to the detriment and segfaults of all
Not only is `national' no use, but such a list would be only tempting fate - there's nothing stopping a spammer sucking a few addresses off it and misusing them, then you've still got to get off your ass and persue them.
And, of course, this is basically legal recognition that some forms of spam are acceptable - it's opt-out not opt-in.
"Why does everyone seem to think that the right to free speech covers everything a body might want to say about anything?"
Because it does - at least insofar as if you're going to abstract slightly from "one person" to "an organizational body", when you might as well also abstract slightly from "speech" to "publish content".
What you don't like comes under *responsibility* attendant with the freedom of speech.