Re: GI Joe is a perl user
Jonathan Stowe wrote: On Thu, 31 Oct 2002, Dominic Mitchell wrote: [1] Even though Bill Joy threw out the code he was given and wrote his own. ;-) And then found time to start on vi too And csh, and the r* commands, and I think he did some of the initial work on virtual memory for early BSD, too. Quite the over achiever. http://www.oreilly.com/catalog/opensources/book/kirkmck.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: webmail
At 05/11/2002 01:20 [], David Cantrell wrote: On Mon, Nov 04, 2002 at 01:38:49PM +, Shevek wrote: I do try to stay out of the opinion ring but this, in my opinion, is a steaming pile. Scaling mod_perl up to a few hundred hits a second isn't hard. Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. Perhaps heretically, I disagree. Until perl can be used (transparent of web server api engines, which don't do a fantastic job anyway) in such a way that multiple concurrent hits doesn't involve an equal number of concurrent running perl instances, cgi perl will not (subject to reasonable hardware constraints) be much use for 100s of instances. Just my $0.02, this isn't intended as a flame. /rataxis -- S. Joel Bernstein :: joel at fysh dot org :: t: 020 8458 2323 Nobody is going to claim that Perl 6's OO is bolted on. Well, except maybe for certain Slashdotters who don't know the difference between rational discussion and cheerleading... -- Larry Wall
Re: webmail
On Tue, Nov 05, 2002 at 01:20:15AM +, David Cantrell wrote: On Mon, Nov 04, 2002 at 01:38:49PM +, Shevek wrote: I do try to stay out of the opinion ring but this, in my opinion, is a steaming pile. Scaling mod_perl up to a few hundred hits a second isn't hard. Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. Definitely on the difficult side of hard :-) $ time perl -e '$a = `perl -le print q[hello]` for (1..200)' real0m1.068s user0m0.600s sys 0m0.380s $ host -t hinfo paulm.com paulm.com HINFO Intel-1.8GHz-P4 Debian-GNU/Linux $ For fun, $ time perl -e '$a = `perl -MCGI -le print CGI-header, CGI-h1(q[hello])` for (1..200)' real0m10.329s user0m8.400s sys 0m0.990s $ Heh. Paul -- Paul Makepeace ... http://paulm.com/ What is between a duck? A female grizzly and her cub. -- http://paulm.com/toys/surrealism/
Re: webmail
On Tue, Nov 05, 2002 at 03:20:57PM +, Paul Makepeace wrote: On Tue, Nov 05, 2002 at 01:20:15AM +, David Cantrell wrote: Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. Definitely on the difficult side of hard :-) Agreed. $ time perl -e '$a = `perl -le print q[hello]` for (1..200)' real0m1.068s user0m0.600s sys 0m0.380s $ host -t hinfo paulm.com paulm.com HINFO Intel-1.8GHz-P4 Debian-GNU/Linux $ For fun, $ time perl -e '$a = `perl -MCGI -le print CGI-header, CGI-h1(q[hello])` for (1..200)' real0m10.329s user0m8.400s sys 0m0.990s $ $ time perl -e '$a = `perl -le print q[hello]` for (1..200)' real0m2.353s user0m1.350s sys 0m0.960s $ time perl -e '$a = `perl -MCGI -le print CGI-header, CGI-h1(q[hello])` for(1..200)' real0m22.025s user0m19.560s sys 0m2.350s Here's the first 1%: $ time perl -e '$a = `perl -MCGI= -le print CGI-header, CGI-h1(q[hello])` for(1..200)' real0m21.659s user0m19.370s sys 0m2.280s Scarily, here's another 29%: time perl -e '$a = `perl5.00503 -MCGI= -le print CGI-header, CGI-h1(q[hello])` for(1..200)' real0m15.654s user0m13.930s sys 0m1.610s (perl was 5.8, 5.6.1 built by me, so probably the same compiler options as the other two is: real0m20.931s user0m18.340s sys 0m2.470s ) I think using 5.005_03 is a fair speedup, given that your example isn't using any 5.6.1 features (yet), and isn't tickling any 5.005_03 bugs. Obviously real optimisation problems aren't this simplistic. Nicholas Clark
Re: webmail
S == S Joel Bernstein [EMAIL PROTECTED] writes: Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. S Perhaps heretically, I disagree. Until perl can be used (transparent S of web server api engines, which don't do a fantastic job anyway) in S such a way that multiple concurrent hits doesn't involve an equal S number of concurrent running perl instances, cgi perl will not S (subject to reasonable hardware constraints) be much use for 100s of S instances. Depends on your hardware, and that's also why this is hard, but not impossible. If you have smaller hardware, you need mod_perl. But that's not what was said here. S Just my $0.02, this isn't intended as a flame. Pay closer attention to context next time, please. That's not a flame either. That's just a whack upside the head. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
REVIEW: Linux Device Drivers (second edition)
Note that this is not well formed POD according to the current podspec, as Lfoo|http://bar/com is (currently) not a legal way to specify a link. So an automatic HTML conversion of this will probably need tweaking. Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/ =head1 Linux Device Drivers (2nd Edition) by Alessandro Rubini Jonathan Corbet I was interested in reviewing the second edition of this book, because I bought the first edition, and wanted to see how they compare. The second edition gives you 592 pages total, across 16 chapters, written by 2 authors covering Linux versions 2.4.x, 2.2.x and 2.0.x. This contrasts with a first edition of 450 pages, B17 chapters, 1 author, covering 2.0.x and 1.2.13. However, those statistics hide the enormous benefits to the rest of the book that the removal of that extra chapter brings. Chapter 17 in the first edition is entitled Recent Developments and gives 20 pages describing the major changes to Linux in the 2.1 development series up to 2.1.43. The first edition had the misfortune to overlap the 2.1 development series, so that by the time it was published in February 1998 it was already partially obsolete, as the 2.1 kernel had reached 2.1.84, and within a year it was out of date when the 2.2.0 kernel was released in January 1999. In contrast, the second edition was published in June 2001, only a few months into the stable 2.4 series, and 2.5.0 was not released until November 2001. Thus over a year later the book is still covering the current stable series, and looks safe for some time to come. The book is also available online under the GNU free documentation licence at Lhttp://www.xml.com/ldd/chapter/book/. I've not checked whether the online version has had updates since the hardcopy edition was committed to press. Although the second edition deals with three distinct versions of the Linux kernel, it manages to almost completely eliminate any complexity that describing multiple versions could have brought. The second edition is much better than the first edition, which could give a feeling of disorientation as it jumped back and forth between the two kernel versions it covered. The second edition achieves its serenity by structuring all chapters so that the main body only deals with 2.4.x series kernels. Example code is presented which will compile on 2.4.x, rather than code cluttered with C#ifdefs, and a note made of changes needed to give backwards compatibility to 2.2 and 2.0 series kernels. The detail of these changes is saved up to a Backwards Compatibility section at the end of each chapter, which keeps the main text flowing along nicely. Concepts or functionality only present in 2.4 (or 2.4 and 2.2) series kernels is clearly marked, as are kernel subsystems now principally maintained for backwards compatibility. This makes it easy to decide what features to use if you are only interested in writing drivers for 2.4 (or later) kernels, and what features to avoid if you want to run on earlier kernels. It also gives the reader a clear idea of how the kernel systems have evolved over time, something that would not be easy to infer with just the kernel sources. The book is carefully structured to build up logically, starting with simpler concepts in the early chapters, and building up logically so that more complex subjects in the later chapters don't require the introduction of many new ideas simultaneously. Hence chapter 2 describes how to build modules load the into a running kernel, configure them, and safely unloaded them when done. This description is all safely concluded before the first mention of how to write device drivers, which begins in chapter 3. The preface says that the book is structured in two parts - part 1 (chapters 1 to 10) give everything you need to know about writing a character device, and move from software towards hardware, whereas part 2 (chapters 11 to 16) cover more advanced topics such as block devices and network devices. The ordering is identical to the first edition, and was dictated because prior to the 2.4 kernels block devices were implemented using many of the structures of char devices. The preface states that all the chapters cover a distinct problem, and generally they do, in a neat self contained fashion. One exception would be that the many small subsections on various features of char drivers collected in Chapters 3 and 5 (Char Drivers and Enhanced Char Driver Operations) have to be ordered somewhat arbitrarily, but I cannot see a better way of smoothing the flow between the disjoint subtopics. Chapter 12 (Loading Block Drivers) covers pretty much everything you ever wanted to know about block drivers (except mmap), request queues, partitioning, and then some. At 49 dense pages I feel that it could have benefited from breaking into 2 chapters (basic block devices, and everything else) possibly with the mmap chapter put between as light relief. But apart from
Re: REVIEW: Linux Device Drivers (second edition)
On Tue, Nov 05, 2002 at 08:34:08PM +, Nicholas Clark wrote: Aargh. I thought I had proof read this. I guess some typos magically reveal themselves only after you've committed it to 1 (or more) online mail archives and the inboxes of 200 or so list subscribers. Surely someone could write igrammar, itypo and iproofread? flowing along nicely. Concepts or functionality only present in 2.4 (or 2.4 and 2.2) series kernels is clearly marked, as are kernel subsystems now are [I presume. (plural || singular) needs a plural verb, doesn't it?] many new ideas simultaneously. Hence chapter 2 describes how to build modules load the into a running kernel, configure them, and safely unloaded them when , load the contribution to the understanding of the concepts illustrated, and their would there Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: REVIEW: Linux Device Drivers (second edition)
On Tue, Nov 05, 2002 at 08:50:34PM +, Nicholas Clark wrote: On Tue, Nov 05, 2002 at 08:34:08PM +, Nicholas Clark wrote: Aargh. I thought I had proof read this. I guess some typos magically reveal themselves only after you've committed it to 1 (or more) online mail archives and the inboxes of 200 or so list subscribers. Like I said. load the into a running kernel, configure them, and safely unloaded them when , load the , load them OK. I'll stop now. Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Usernames?
The traditional restrictions on web usernames are things like only
alphanumerics, and usually lowercase to reduce user confusion/burden
remembering.
I was wondering, why? They seem quite arbitrary in the modern day world.
Why not allow (embedded) whitespace, punctuation, and so on?
The only thing I can see so far being a problem is if the username was
later used for an email address. But, taking that possibility out, what
other reasons are there for these restrictions?
s/^\s+//, s/\s+$//, s/[^\w ]//g, $_ = lc $_ for $signup{username};
unless ($signup{username}) {
$messages = Your username must contain some letters and/or numbers.;
$signuperror{username} = 1;
}
Paul
--
Paul Makepeace ... http://paulm.com/
If I dream the me will come out and I will be free, then I shall
takeover Spain.
-- http://paulm.com/toys/surrealism/
Re: Usernames?
On 5 Nov 2002, Randal L. Schwartz wrote: Otherwise, they're really a lot more flexible. But just try doing tech support with 31337D#d3 as a username. :) Isn't that a perfectly valid AOL or Hotmail username anyway? Elite dude, You've got mail! insert troll=that's also valid perl6, innit? / :) -- Chris Devers[EMAIL PROTECTED]
Re: Usernames?
Paul == Paul Makepeace [EMAIL PROTECTED] writes: Paul The traditional restrictions on web usernames are things like only Paul alphanumerics, and usually lowercase to reduce user confusion/burden Paul remembering. Paul I was wondering, why? They seem quite arbitrary in the modern day world. Paul Why not allow (embedded) whitespace, punctuation, and so on? BasicAuth with htpasswd files would break. Otherwise, they're really a lot more flexible. But just try doing tech support with 31337D#d3 as a username. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Usernames?
On Tue, Nov 05, 2002 at 10:24:42PM +, Paul Makepeace wrote: The traditional restrictions on web usernames are things like only alphanumerics, and usually lowercase to reduce user confusion/burden remembering. I was wondering, why? I think the restriction, at least in regards to lowercase letters, is historic. Early versions of unix supported monocased terminals. I remember a professor telling me that if you logged in and your username was allcaps, the tty would go into a compatability mode AND DISPLAY EVERYTHING IN UPPERCASE, EXCEPT FOR CAPITAL LETTERS LIKE \A AND \B WHICH WOULD APPEAR WITH A PRECEDING BACKSLASH. He used to work at ATT and on Multics machines. So it might be true. Then again, we were undergrads, and he could have been pulling our legs, too. They seem quite arbitrary in the modern day world. So is base 60. Yet it persists. Why not allow (embedded) whitespace, punctuation, and so on? Characters like . cause problems because they've always been illegal. For example, chown accepts a syntax of 'chown user.group' because . is illegal. So chown breaks when you have a username like s.avery or m.thibaut. The shell has certain expectations about when and where # will be used, too. The only thing I can see so far being a problem is if the username was later used for an email address. But, taking that possibility out, what other reasons are there for these restrictions? Voiding basic assumptions about shell syntax and usermode tools, mostly. Z.
Re: Usernames?
On Tue, Nov 05, 2002 at 06:24:31PM -0500, Adam Turoff wrote: Early versions of unix supported monocased terminals. I remember a professor telling me that if you logged in and your username was allcaps, the tty would go into a compatability mode AND DISPLAY EVERYTHING IN UPPERCASE, EXCEPT FOR CAPITAL LETTERS LIKE \A AND \B WHICH WOULD APPEAR WITH A PRECEDING BACKSLASH. He used to work at ATT and on Multics machines. So it might be true. Then again, we were undergrads, and he could have been pulling our legs, too. He wasn't pulling your leg, Linux still does this. andrew -- Sagittarius: (Nov. 22 - Dec. 21) The stars appreciate that you want to protest rampant corporate corruption, but they don't see what you think the giant puppets are going to accomplish. msg08982/pgp0.pgp Description: PGP signature
Perl is someone else's bitch
http://www.stylishgeek.com/cgi-bin/store/cpshop.cgi/1971912010 Kake -- http://www.earth.li/~kake/cookery/ - vegan recipes, now with new search feature http://grault.net/grubstreet/ - the open-source guide to London http://www.penseroso.com/ - websites for the fine art and antique trade
Re: Usernames?
On Tue, 5 Nov 2002 18:24:31, Adam Turoff [EMAIL PROTECTED] said: Early versions of unix supported monocased terminals. I remember a professor telling me that if you logged in and your username was allcaps, the tty would go into a compatability mode AND DISPLAY EVERYTHING IN UPPERCASE This was true, and is still the case today: Debian GNU/Linux testing/unstable camel tty1 camel login: CHRIS PASSWORD: LOGIN INCORRECT CAMEL LOGIN: - Chris. -- $a=printf.net; Chris Ball | chris@void.$a | www.$a | finger: chris@$a | A. No. | Q. Can I post at the top?-- bbc-micro mailing list
Re: Change of plans
On Tue, 2002-11-05 at 02:15, David H. Adler wrote: Well, it's good that we didn't figure anything specific out, as it seems I'm not coming. Due to several different factors (one of which is we're running over to another country to sit in a theatre for 9 hours and come right home? Are we insane? :-), I'll not be coming over at this time. Of course, I'll come over another time. You can't keep me away *that* long... :-) I'm coming over to your side of the pond next week. You lot got anything decent on?
Re: Change of plans
On Wed, Nov 06, 2002 at 07:17:47AM +, Dave Hodgkinson wrote: On Tue, 2002-11-05 at 02:15, David H. Adler wrote: Well, it's good that we didn't figure anything specific out, as it seems I'm not coming. Due to several different factors (one of which is we're running over to another country to sit in a theatre for 9 hours and come right home? Are we insane? :-), I'll not be coming over at this time. Of course, I'll come over another time. You can't keep me away *that* long... :-) I'm coming over to your side of the pond next week. You lot got anything decent on? Nothing planned. Should we go get beer or something? I'm willing to call a meeting at even the slightest provocation, you know. :-) dha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ Damn, if this doesn't win me Pedant of the Year, I don't know what will.- Mark Rogaski
