Re: minimal Unix chat system
Dave Long writes: a propagation delay averaging about half a second ... which is tail(1)'s fault; if one really cared, and had a usleep(1), another sh read loop would handle output w/o the noticable delay. tail has a -s option which could benefit from accepting floating-point numbers, which would eliminate that problem. 1/ C++ programmers switching to Lisp should do just fine! In my experience, C++ programmers are not very good at getting good performance --- or their C++ is very C-ish. 2/ Is it only Lisp programmers switching to C who reimplement half a Common Lisp because they think that, until a program can be expressed at a high level of abstraction, it's not done? Your statement is somewhat ambiguous; perhaps only Lisp programmers do it for that reason, but dyed-in-the-wool C programmers do it too, for a different reason. I suspect Lisp programmers doing it would tend to do it in a better-thought-out way. Perhaps because C programmers are used to it being unusual for a simple program text to be difficult for the iron. ... it is probably also the mark of an inexperienced tool vendor to force discovery of the correct way by abysmal performance for the first-glance way. What's the alternative? As in C, to require tasks that are difficult for the iron to be expressed verbosely? Sometimes I want to do tasks that inherently take a lot of computation, and I prefer to be able to express them as concisely as possible. Thus SQL, awk, regexes, and Common Lisp. The modern world progresses by an increase in the things that are successfully done ineptly. How old is this idea? -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ We have always been quite clear that Win95 and Win98 are not the systems to use if you are in a hostile security environment. -- Paul Leach The Internet is hostile.-- Paul Leach [EMAIL PROTECTED]
Re: minimal Unix chat system
Kaushik Sridharan writes: The modern world progresses by an increase in the things that are successfully done ineptly. How old is this idea? It is a profoundly erroneous truism, repeated by all copy books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them. -- Alfred North Whitehead (1861-1947) 'An Introduction to Mathematics' That's where I heard it last, I think --- thanks for finding the quote. Whitehead and the copy books and eminent people he criticizes could both be right, and I think both are. Frugality advances by extending the number of important things we can do without spending money on them, and by decreasing the amount of money we have to spend on things we have to spend money on, but it does not therefore follow that we should try to have less money to spend. The civilization of which Whitehead speaks is a kind of frugality of mental power. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ A good conversation and even lengthy and heated conversations are probably some of the most important pointful things I can think of. They are the antithesis of pointlessness! -- Matt O'Connor [EMAIL PROTECTED]
programming environments, C Lisp (was Re: minimal Unix chat system)
Dave Long writes: To my tastes, Lisply written Fortran is no better than Fortranly written Lisp) Lispy Fortran is probably good if you have to write an optimizing compiler or a regular expression engine in Fortran, and Fortranny Lisp is probably good if you're writing an FFT engine. Lisp is probably better than Lispy Fortran for Lispy problems; the argument you make in the section on tools from different levels of abstraction seems to be that Fortran (or C) is better then Cish or Fortranny Lisp for Cish or Fortranny problems, too. Several years ago, when I was doing a fair amount of cross-platform work, Richard Gabriel's message* hit home: * but see http://www.dreamsongs.com/WorseIsBetter.html Microsoft was fairly good at having numerous calls like ScrollWindow, that did more or less what one might expect. If, later on, one found out that Foobar didn't quite do what was needed, often a FoobarEx call existed that would. On the Mac and under X, even simple tasks sometimes involved poking about in other people's code or a copy of Inside Macintosh to figure out just what the magic incantation was. ... So because ignorant code tended to work (and was improvable with only slightly less ignorance), Windows was a more productive environment, for the novice developer. (and if one wishes for popularity it does well to remember the population is mostly novices) So the Windows API is like Common Lisp and unlike C in this way, no? I am ambivalent about making ignorant code work. This is rather the problem with Lisp than the solution --- the ignorant matrix-multiply given in Good News, Bad News, How to Win Big did work, but it was slow. It's also a problem in Perl; you can do things like symrefs instead of having to learn about references or hashes, so you can be more ignorant and write code that works --- until it gets the wrong input... Generally there seems to be a conflict between making it easy to get code working and making it easy to have confidence that code that works in one situation will work in another. Perl is not very good at the latter; it's the major reason I (often) prefer Python. The Windows approach, though, of adding functions with guessable names that do common tasks, is a very good one. FAQ entries should become library functions. Maybe all that Lisp needs is a good reference work -- cross-indexed by the sorts of things C programmers are likely to want to do, with text that says instead of writing code like this: ..., try this: ...? That's going to be hard to keyword-search, I think. Perhaps the compiler could notice when you do things unnecessarily inefficiently. (Indeed, the CMUCL compiler can notice, and there are sections in the manual explaining what it's talking about and how to fix it.) Perhaps because C programmers are used to it being unusual for a simple program text to be difficult for the iron. What's the alternative? As in C, to require tasks that are difficult for the iron to be expressed verbosely? Sometimes I want to do tasks that inherently take a lot of computation, and I prefer to be able to express them as concisely as possible. Thus SQL, awk, regexes, and Common Lisp. Exactly -- when you wish to solve a problem for which C isn't concise, you use a different tool. As long as it's easy to couple tools from different levels of abstraction, I'm not convinced it's such a big win to stretch one tool across all levels. You might be right that if it were easy to couple tools from different levels of abstraction, it wouldn't be such a big win; but the antecedent in this implication is false, so nothing can be concluded about the truth of the consequent. .NET's CLR is an attempt to change this; it remains to be seen how effective it will be. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ A good conversation and even lengthy and heated conversations are probably some of the most important pointful things I can think of. They are the antithesis of pointlessness! -- Matt O'Connor [EMAIL PROTECTED]
Re: identifying texts with zlib
Dave Long writes: Cool. It shouldn't require that much redundancy* to guess that information; It looks like an order-4 markov chain (by letters) produces English-looking output, and an order-2 one (by words) is best for parody, as word-order-3 results in long source text runs. [0] So you can just calculate the probability of a document being produced by such a model? That should work quite nicely. Joshua Goodman at Microsoft Research, in his Extended Comment on Language Trees and Zipping, complained that the zlib classification didn't perform as well as a naive Bayesian classification scheme for classifying newsgroup posts (a sort of topic choice problem), so the hype given to this gzip hack was unwarranted. http://arXiv.org/abs/cond-mat/0202383 Is there an easy way to pick up the most common combinations of lengths 2...N? Suffix trees, maybe? That should work --- you'd probably want to augment the suffix tree with weights giving the number of nodes in the subtree under each node. It seems that some combinations of characters (such as s. ) don't give nearly as much information about what follows them as other combinations of characters of the same length (such as d th). If you built a weighted suffix tree as above and then pruned all the subtrees smaller than a certain size, you'd have a sort of skeletal suffix tree; I think you could use it to generate better fake text than any fixed-order Markov model built from the same input text or any fixed-order Markov model of the same size. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ We are forming cells within a global brain and we are excited that we might start to think collectively. What becomes of us still hangs crucially on how we think individually. -- Tim Berners-Lee, inventor of the Web
Re: identifying texts with zlib
Dave Long writes: Cool. It shouldn't require that much redundancy* to guess that information; It looks like an order-4 markov chain (by letters) produces English-looking output, and an order-2 one (by words) is best for parody, as word-order-3 results in long source text runs. [0] So you can just calculate the probability of a document being produced by such a model? That should work quite nicely. Joshua Goodman at Microsoft Research, in his Extended Comment on Language Trees and Zipping, complained that the zlib classification didn't perform as well as a naive Bayesian classification scheme for classifying newsgroup posts (a sort of topic choice problem), so the hype given to this gzip hack was unwarranted. http://arXiv.org/abs/cond-mat/0202383 Is there an easy way to pick up the most common combinations of lengths 2...N? Suffix trees, maybe? That should work --- you'd probably want to augment the suffix tree with weights giving the number of nodes in the subtree under each node. It seems that some combinations of characters (such as s. ) don't give nearly as much information about what follows them as other combinations of characters of the same length (such as d th). If you built a weighted suffix tree as above and then pruned all the subtrees smaller than a certain size, you'd have a sort of skeletal suffix tree; I think you could use it to generate better fake text than any fixed-order Markov model built from the same input text or any fixed-order Markov model of the same size. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ We are forming cells within a global brain and we are excited that we might start to think collectively. What becomes of us still hangs crucially on how we think individually. -- Tim Berners-Lee, inventor of the Web
Re: grep on RFC-822 headers and stuff
A few notes. sgrep is pretty darn cool. I think its home page might still be at http://www.cs.helsinki.fi/~jjaakkol/sgrep.html or it might not, but it's in Debian, anyway. It looks like it can grep RFC-822 headers with ease. The Emacs forms library looks pretty nice, albeit primitive. It took me a while to get it to work. (Don't put -*- forms -*- in your control file. I got File mode specification error: (wrong-type-argument stringp nil).) It gives you a per-record view of a tabular data file; the data file has one record per line with fields separated by a separator character (tab by default), and the fields get poured into this template you give it. You have keyboard commands for next and previous record and next and previous field, and keyboard commands for searching through the file; and you have typefaces that distinguish old field contents, edited field contents, and window dressing. The Emacs widget package replaces part of the forms package, but not all of it. Hyperbole doesn't have anything related at all. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ Operating personal computers now requires us to devote as much time to set-up menus, installation programs, configuration wizards, and help databases as we do running productive applications. --- Carl Sassenrath
Re: dynamic calculation
Dave Long writes: I find the traditional REPL extremely annoying for use as a desk calculator. I like spreadsheets a lot better, but I don't have any decent spreadsheets on my laptop. How is Gnumeric these days? I haven't tried it --- I'll probably install GNOME on my laptop next month. Or maybe not. We'll see. Perhaps it's perverse to write a new kind of calculation program instead of installing a spreadsheet. Are there any packages that might calculate what-if's as a logical/ philosophical sort of spreadsheet? . . . For those of us who like to believe that we change our minds upon receipt of new information, it would be neat to have mechanical ways of exchanging and comparing arguments. I think these are commonplace in AI-land, as I recall reading about them. I'm not sure what they're called, though --- they might be truth maintenance systems, but I'm not sure if that's the right thing or something else entirely. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ Techno addiction. More expensive than crack, keeps you up longer than coke, makes you fatter than pot, but hey... it's legal. -- Tim Byars [EMAIL PROTECTED]
Re: spam [Re: dynamic calculation]
Dave Long writes (on FoRK): Would it be possible to mess with the input parameters (SO_RCVBUF to 1 and poll infrequently?) such that a black- holed connection would be just incredibly, instead of infinitely, slow? I would prefer that my personal mail took 10 min/k to be delivered than the current situation where it isn't delivered at all. I think this is an excellent idea, and (at least on Linux 2.4) it is indeed possible to set SO_RCVBUF low and poll infrequently, thus achieving a slow TCP connection. (I just tried it.) I think some folks have tried higher-level versions of this to try to suck up spammers' resources --- when they detect a spam in progress, the SMTP server begins to insert time delays before answering SMTP messages, thus holding the connection open longer. I think this is called teergrube, or tar-baby. If the USPS is any indication, spammers have more commercial clout than we individual end users, anyway. Junk-mailers pay the USPS, and (so I've heard) pay most of its expenses; they don't pay ISPs, and quite the contrary, they cost ISPs quite a bit of money. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ Then the object is collected. The finalizer is not run a second time. Can you cast a spell to resoul an undead object? Do the resouled undead differ from the living? -- Charles Fiterman on [EMAIL PROTECTED]
Re: cult software
Dave Long writes:
[quoting Kragen]
Chuck's vision for FORTH was not that it would be a fancy macro
assembler (or, at least, not that it would be used for the things
assemblers are used for today). He wanted it to be the user
interface, the application programming language, the scripting
language, and also the device-driver and kernel language.
But isn't his vision that, if one truly codes, an interactive macro
assembler is more than sufficient for all those domains? *
It's a matter of definition, I guess --- thus the parenthetical caveat
in my message above.
* what were early Mac apps written in? Pascal or assembler? I
think the UI, drivers, and kernel were almost all assembler.
I know they had to fight pretty hard to get it all into their tiny
ROM, so I wouldn't be surprised. But I don't know.
I agree that a language doesn't need to include preemptive
multitasking, virtual memory, and a filesystem. But it is useful to
have these things in your development environnment, and FORTH is also
a development environment.
Preemptive Multitasking -- hang a scheduler off the timer interrupt.
You can add it, sure, especially in a single-user FORTH system.
(Messing with the timer interrupt on a multi-user FORTH system might
be rude --- what if someone else was using it?) But you can say the
same thing about a machine with only a ROM monitor that lets you type
in octal machine code.
Virtual Memory -- is it *really* necessary? (stream large images,
etc.) if so, initialize the page tables and hang some code off the
page fault interrupt.
No, it's not necessary, but it is sometimes useful.
Filesystem -- I like filesystems, but SmallTalkers are mostly happy
with system images. I wonder how Chuck handles his CVS-like needs?
I hate filesystems, but direct disk access by block number is not an
improvement for most things.
I think there may be parallels in the early days of micros. Real
computers had {pm, vm, fs}'s, but micro people could get stuff done
with no pm, no vm, and very little fs. run light without overbyte
(even if DDJ no longer does)
Yes --- this is one reason FORTH was so popular in the early days of
micros.
I think reading Chuck's code would make me a better programmer, even
if I don't program like Chuck ...
I have an ascii version of the code and shadow blocks for COLOR.COM,
if you'd like.
I'd like very much to read them; I just never got around to running
ColorFORTH, so I never extracted them.
His character encoding is an interesting design decision; it both
avoids byte accesses (which were annoying on the early Alphas) and
allows his dictionary lookup on x86 to be mostly repne scasd.
The old traditional FORTH name structure consisted of a single length
byte followed by the first three characters of the name;
interestingly, this could also have been scanned by repne scasd
(except, of course, that the names were in a linked list, not an
array; and the processors of the time didn't have 32-bit registers or
scasd, just scasb and scasw.)
--
[EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/
[around 1998-12-23], it is amazing to watch fear and loathing and greed at
play with the more speculative Internet stocks. To call this a tulip
craze would be a vast understatement. -- Adam Rifkin, [EMAIL PROTECTED]
Re: magic boxes and secret knocks
This is really cool! The actual experience of standing across the room and whistling at my computer --- and seeing it recognize my call --- is exciting. However, it is really annoying Beatrice at the moment, so I'm going to have to tune this more some other time. Dave Long writes: It works off of the zero-crossings from /dev/audio, and is tuned for what my mic. produces. Enable the debugging output to tune the band bucketing calculation. I tried much fancier approaches, with mexican hats and derivatives thereof, but none of them seemed to work any better. FWIW /dev/audio normally produces mulaw logarithmic-scale output, which is probably better than linear output for visual analysis, but will pretty thoroughly foil wavelet analysis. Did you correct for that? (I guess I should try it.) I'd expect good results from zero-crossing analysis unless there was (any) high-frequency noise or (large p-t-p amplitude) low-frequency noise. It seems to be relatively easy to get false positives from fan noise on my laptop, unfortunately. What's ups[9] for? -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ A well designed system must take people into account. . . . It's hard to build a system that provides strong authentication on top of systems that can be penetrated by knowing someone's mother's maiden name. -- Schneier
Re: derivative games (at last)
You write: This game doesn't make any sense. It keeps telling me I won and I don't know what I did. If I just let the game sit by itself I still end up winning most of the time. You are experiencing my masterful UI design in action. It shouldn't say you win, and certainly not in another window, but I hadn't gotten to fixing that yet. But I hadn't made any actual improvements in six hours or so, so I figured I'd better release the software :) You win means you have won that stage and are proceeding to the next stage, where there is one more dot. You can usually win the first stage without trying; its purpose is to orient you. What is the goal? Am I supposed to get the dot to the center? What about when there are 2 dots? do I get both the center at the same time? I can't tell b/c I win so randomly. When the game ends and the window disappears, you have lost. Your goal is to keep that from happening for as long as possible; a new dot appears every five seconds, which should help you to keep track of time. I have made it to five balls a few times, but then I made the game harder. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ This is exactly how the World Wide Web works: the HTML files are the pithy description on the paper tape, and your Web browser is Ronald Reagan. -- Neal Stephenson, at http://www.cryptonomicon.com/beginning_print.html
Re: which is better, python or perl? And more importantly, why?
This kragen-tol article was published (with some of the mistakes removed) in ;login: this month; I had the following interesting conversation with a reader, which I repost here with his permission. Date: Thu, 13 Jun 2002 14:32:50 -0700 (PDT) From: Simon J. Gerraty [EMAIL PROTECTED] Subject: Re: python indent sensitive Hi, I was reading your article in ;Login: regarding python cf. perl. In your comments about python being indentation sensitive you assert that anyone who finds this silly is an unthinking moron. I recall looking at the python web pages some years ago - since python sounded cool, and saw a claim that there is a very good reason python doesn't use braces, but that reason was never given. Since you clearly hold that python's indentation sensitivity is a bonus, perhaps you could explain why - with actual reasons that is. Its possible I'm wrong to think that python would have been a very good language if only it used braces for grouping rather than indentation, but absent something a bit more convincing than its better, I can only imagine it being a source of hard to track bugs. Thanks --sjg Date: Thu, 13 Jun 2002 18:52:15 -0400 From: Kragen Sitaker [EMAIL PROTECTED] Subject: Re: python indent sensitive Simon J. Gerraty writes: I was reading your article in ;Login: regarding python cf. perl. In your comments about python being indentation sensitive you assert that anyone who finds this silly is an unthinking moron. I haven't seen the printed version yet, but I think I said that certain kinds of unthinking morons (your words, not mine) didn't like it, but I specifically said there might be reasons other than being an unthinking moron that one might not like it. Many people who unthinkingly adhere to stupid traditions (my words from the article) are quite intelligent. Since you clearly hold that python's indentation sensitivity is a bonus, perhaps you could explain why - with actual reasons that is. With braces, I have to say what I mean twice --- once with the braces, so the compiler can understand me, and once with indentation, so humans can understand me. If I get it wrong, I have an unseen bug. As a C, C++, and Perl programmer, I eventually developed very sharp eyes for things like this: if (foo) debug_printf(foo happened\n); barf(); do_something_else(); In Python, I don't have to waste my attention on that any more. Whitespace is a preattentive feature; it is processed by my retina and visual cortex without any conscious attention on my part and very little effort, and I can see *all* of the whitespace in a large visual display in less than a quarter of a second, about the time it takes my eye to move from one spot to another. It is a major benefit to be able to understand the nesting structure of a whole screen or page of source code automatically and with no effort. That is why indentation to show nesting in source code is universal today. Python simply removes the possibility that your subconscious, preattentive understanding of your program's structure is incorrect. Knowing that a program is written in Python also eliminates the possibility that it is unindented; an unindented C program can be run through 'indent', but an unindented Perl program is a nightmare. People occasionally suggest that this lack of redundancy will lead to bugs, as a misindented statement won't be noticed later. (Specifically, a statement that should be inside a block being after the block, or vice versa.) I've introduced lots of bugs in programs, and I have kept exhaustive records of the bugs I found in many small programs. I cannot recall any bugs of this nature in my Python or Perl programs, but I have introduced this kind of bug a few times in C and C++ programs, usually in the way shown above. It is rarely subtle in its effects, but it is often hard to find. I don't argue that redundancy is always bad, but that in this particular case, the redundancy proves not to be worth its price. For my thoughts on when redundancy in syntax (and programming languages in general) is a good idea, see http://lists.canonical.org/pipermail/kragen-tol/2002-April/000705.html Lisp syntax considered insufficiently redundant and http://www.paulgraham.com/redund.html Redundancy and Power. Subject: Re: python indent sensitive Date: Thu, 13 Jun 2002 17:44:08 -0700 From: Simon J. Gerraty [EMAIL PROTECTED] Hi, I dropped the login address [the original mail was Cc:ed to [EMAIL PROTECTED]] - since it was wrong anyway :-) Since you clearly hold that python's indentation sensitivity is a bonus, perhaps you could explain why - with actual reasons that is. With braces, I have to say what I mean twice --- once with the braces, so the compiler can understand me, and once with indentation, so humans can understand me. If I get it wrong, I have an unseen bug. As a C, Hmmm, interesting. I'm thinking more of the case where I put the braces in and the editor does the indenting
Re: blogging via IRC
Dave Long writes: [quoting Kragen] ... the convenience of blogging stuff through GAIM will have a major effect on what I blog. (and so it has) Instead of navigating to a data entry screen and filling in the blanks, you can just type the proper incantation? Sounds almost like a shared, social, reinvention of the command line. It's a little different; the things I blog are more like documents than like commands. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ Edsger Wybe Dijkstra died in August of 2002. The world has lost a great man. See http://advogato.org/person/raph/diary.html?start=252 and http://www.kode-fu.com/geek/2002_08_04_archive.shtml for details.
Re: [kra...@canonical.org: Re: PEGs]
Dave Long dave.l...@bluewin.ch writes: A design that I'd like to try sometime would be to try an Elephant- like language, in which all values would, in principle, be recoverable from a logfile. This could eliminate GC, as frequently used values would tend to be instantiated in a cache, and values that are never referenced again would cost just their portion of storage, presumably amortized by bulk sequential i/o patterns. This is a fascinating connection! (For the readers who don’t know what Dave’s talking about, Elephant was John McCarthy’s recent proposal for a really different kind of programming system; as I recall, the basic idea is that you specify the kinds of promises your program has to keep, and the system figures out how to keep those promises based on a complete log of the past I/O behavior of your program.) I’ve been thinking a bit over the years about logfile-based programming as well; the “rumor-oriented programming” post was about it. (The basic theory is that if you write your application to not be sensitive to the order of items in the logfile and if there’s no mutual-exclusion validity criterion for logfiles, you automatically get an application-agnostic synchronization protocol, and you forever avoid the problem of database schema migration.) My theory was that you could define the objects of interest to your application in terms of queries on the history, in a FRP-like way. (Although I was thinking SQL, not Haskell.) But the connection between GC and paging sounds really fruitful. Suppose you chose to eliminate GC by telling the OS that the pages you allocated for results derived from history didn’t need to be preserved at all; if the OS wanted to evict them, it could do so merely by deleting them from your mapping and zeroing them for another process to use. Now if you try to access them, you get a segfault, and the segfault handler can put the requesting thread to sleep and enqueue a query to recompute the data that it had wanted. So you rely on the OS’s paging mechanism to manage the caching of your computational results. Is that more or less what you have in mind? This way, the usual overhead of checking weak-reference validity, or sending weak-reference notifications when finalizing a weakly-referenced object, gets shoved off on the MMU hardware. It seems like it might have poor space efficiency: you might end up with 100 pages that stay alive because they contain 150 frequently-used objects, each of which is only, say, 32 bytes, while the rest of those pages is taken up by dead objects. In the context of parsing, I was thinking that references from the stack (from function arguments or partly evaluated expressions) would be strong references that would promote objects to older generations; does that generalize to the paging scheme? You could perhaps allocate space for the values of subexpressions on the stack so they don’t get deallocated before you use them, then move them to the heap once they were no longer part of a live subexpression or function argument, but it seems like somewhere you need to store away the context you need to recreate those results if you need them again after they get recycled. In the PEG-parsing case, that information is just a position in the source text and a reference to a nonterminal. (The source text and nonterminals don’t need to be garbage-collectable.) But in an Elephant-like system it seems that your query could be some arbitrarily complex expression. Can you guarantee not needing GC for the query too? Alternatively you could realize your Elephant idea using a generational GC in the same way I was suggesting for caching of PEG results, with a more traditional implementation of strong and weak references. Any idea how mutation rates compare for various workloads with main memory and/or disk bandwidths? I don’t even know where to begin. Maybe some of Ben Zorn’s quantitative research on garbage collection and allocator performance might come close? Kragen -- To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss
Wake Up World! Meet the New Boss, Same as the Old Boss
If you want to know who the real establishment is in America and around the world, the real power behind the so-called ''military-industrial complex'', the real maleficent power that has led this world to inexorable conflict, war, hatreds, destruction of real human values, morality, conscience it is the global media establishment. This same media witnessed the Zionist slaughter of 1,300 people in Gaza, and the maiming of 6,000 more, half of them women and children. More than 20,000 homes and buildings were destroyed or damaged and thousands became homeless. This horrendous mass slaughter of Palestinians is compared to the loss of 3 Israeli civilians. Yet, the media never dare to call this slaughter exactly what it is: terrorism on a horrendous scale! This same American and global media has not informed the American people or the people of the world of the damning truth about Barack Obama. In truth, Obama is a complete creation of extremist Jewish Zionists and he has already begun to serve Israel by his top appointments. The Jewish-dominated media in America is promoting the Obama inauguration as akin to the Second Coming of Jesus Christ. (If you question Jewish control of the media read Who Runs the Media? and you will find documentation proving the Jewish control being far greater than you might suspect) The rest of the worlds powerful media (Which also has a powerful Jewish presence in the UK, France, Spain, Sweden, Russia, and the rest of Europe) takes its cues from the NY/Hollywood media axis, and presents Obama as kind of a superhuman agent of real change. In fact, it is a Huge Lie! Obama is completely controlled by the same forces that have controlled George Bush, so much so that The Chicago Tribune quotes leading Jews bragging that Obama is so in the hands of the Zionists that he is ''the first Jewish President.'' Obama received about 80 percent of the Jewish vote in the United States! The Three critical things that made Obama President: 1)Jewish political influence Obamas chief handler is David Axelrod, a radical Jewish Zionist whose previous claim to fame was the fact that he was the Zionist political hit man against Illinois Senator Charles Percy, who was not deemed to be pro-Israel enough. (He was only 99.9 percent Israels lackey, not the required 100 percent) Obama went to Israel and made sure he pronounced himself even more radically pro-Zionist than Bush or McCain. 2) Massive amounts of Jewish money Obamas campaign was kicked in high gear by Jewish Hollywood and financial moguls. In just one of the early fundraising parties in Hollywood by Spielberg, Geffen and Katzenburg it raised over a million dollars for Obama. Obama raised more money than any political candidate in American history and his biggest contributors were overwhelmingly Jewish activists, Jewish international finance and banking firms and Jewish globalists. His largest single contributor was the international Jewish Banking firm of Goldman Sachs. He received more money from the same international bankers that ripped off trillions of dollars in the recent economic scandals than even John McCain. Is a man totally under the power of the most powerful financial organizations in the entire world, really an agent of ''change?'' 3) Overwhelming positive support in the Jewish-dominated media By a large margin, Jewish-owned media officially endorsed Obama, and that is not counting tens of thousands of positive articles by Jewish; owned publications and pundits. Obamas first act as President-elect was to appoint a Jewish extremist, dual citizen, Rahm Emmanuel, as his chief of staff. As the people of Gaza were slaughtered, Obama would not make a single statement to stop this murder and maiming of thousands of innocents! Israel, very carefully timed its terrorist attack on Gaza to be in the remaining days of the Bush Administration. The day before Obamas inauguration Israel announced that it would be completely out of Gaza by the time Obama took his oath of office. Why? Before Obama took office, Israel could make this terrorist slaughter against Palestinians and Obama would still be perceived as having clean hands. Because Obama is completely under their control, they want him to have an image of fairness, honor and peacefulness, and as representing a new direction of American policy, as he begins to deal with the Mideast turmoil. Since he is Israels boy in the White House, what better scenario could they have than a President perceived as practically the Second Coming, of high moral conviction, and dedicated to fairness, but who is actually bound hand-and-foot to the Zionist agenda, just as the last presidents have been. Talk about a perfect shill. And the game is working, for even many Palestinians are filled with hope that the new President will work to end their long suffering. With an almost godlike positive image around the world, a Barack Obama who is
