The IRA do not attack U.S. targets -- but they train terrorists who do. Even if they didn't train other terrorists, the IRA, like ETA, Hamas, Osama bin Laden, etc, is evil.
The IRA is the easiest target: search every house in Northern Ireland and the vicinity; take every ounce of cemtex, every gun. And let the British and Irish governments do this together. And get the unionist terrorists while we're at it.
As for the Taliban: use Russia's help and invade, or invade via Pakistan (give Pakistan no choice). Hunt down these fuckers.
The ETA, Hamas, Hezbollah, ... -- all of them must be destroyed.
And warn the Colombian guerrillas and paramilitaries that their next if they don't cool it.
Thanks a lot for your help!
What a bunch of reckless, dangerous, young moral relativists.
Twenty years from now they'll be like the baby boomers of today who used to be the protesters of the 60s and who they emulate; they'll be the greedy make-our-granchildren-pay-for-our-retirement types.
So now you can use RPCSEC_GSS for NFS authentication, which means you can use any GSS mechanism for which you have a plug-in (Sun supports the old Diffie-Hellman based NIS+ system, new variations of that with longer keys and Kerberos V). Specifications for other GSS mechanisms exist; see the IETF RFC Search and the RFC draft repository (search for GSS and Generic Security Service).
Because RPCSEC_GSS does not change existing ONC RPC protocols it can be used to secure NFSv2 and NFSv3. But software changes are needed.
Solaris 2.6, 7 and 8 all support RPCSEC_GSS and secure NFS.
NFSv4 also uses RPCSEC_GSS and, as part of the NFSv4 for Linux initiative a Linux implementation of RPCSEC_GSS is already available for Linux. I haven't followed the Linux NFS situation very closely, but it might be possible to do secure NFS with Linux now or, if not now, soon.
NFSv4 probably shouldn't be called NFS anymore. It fixes all/most of the NFSv problems. For example, NFSv4 is stateful (i.e., it has open/close calls), using a variation on the BSD NQNFS file leasing approach; it supports NFS proxies; NT-style ACLs; NT-style open modes; compound RPCs (one packet, multiple calls); the mount protocol goes away; etc...
One more thing, all of Sun's ONC RPC framework is available under the SISSL, IIRC a very liberal license which essentially says you can do whatever you want with the code, even modify and improve it while keeping your mods private, as long as you publish any extensions to the interfaces and reference code also under the SISSL.
Another very good book is AMOP.
I'll look into the delcare bit. Thanks!
BTW, I'm one of the few proud owners of a copy of "On Lisp", one of the best computer science books ever. The fascinating thing is that Paul Graham wrote Yahoo Shopper in Common Lisp and made millions doing it. In LISP!
I've been thinking about Lisp a lot recently.
I think Lisp could use a few small extensions. One would be to make CONS sub-classable. This would help, for example, with XML, kinda like Perl 6's [vapourware] per-scalar, per-symbol property values, but I also see much value in writing a compiler: code analysis information could be stored in new fields in the conses of an s-expression without modifying the form of the expression. Such an extension would also require an extension to dot notation so extended conses could be printed and read.
Another extension that would be nice is what I think of as "forward closures", much like Pascal or GCC local functions, which are closures that are defined only as long as the parent function instance does not exit. There is a safety issue with such forward values, of course, but the value of forward closures is that it can make continuation passing style code more efficient by not requiring heap storage for captured variables. And this (CPS) is needed to implement logic programming languages like Prolog or Icon. And I would really like to be able to program in Lisp with Icon semantics.
But this is all kinda academic... I'm not working on that sort of stuff...
lkcl: dunno who nigel is :), but why would you port Python code to C (speed?)? or think that porting python to C would be easy?
Porting python to Lisp might be easy.
Once you're porgramming at a high-level, to go back to the low-level is hard -- a straight port would require list/hash table libraries, maybe ffcall and the like, all of which makes it pointless to go to the low-level. It would be better to just have a decently fast high level language.
Mind you, I'm not trying to evangelize. You do what you want :)
Besides, there's no ideal computer language, though Lisp gets pretty close (IMNSHO).
lkcl: sounds like you're doing non-deterministic stuff, like you could use a language that has backtracking and pruning built-in. Something like Prolog, or Icon.
Think about it. You could post diary entries, articles, replies, URLs, messages to individuals, certifications and messages to mailing lists via e-mail. One neat side-effect of this would be the ability to use PGP/GPG for post authentication.
Take a look at lkcl's demo site, or the Open-IT site (which uses lkcl's mod_virgule) for an idea of what could be done with the Advogato model. Pay close attention to the concept of interest certifications and searching based on a seed person's certifications. Very cool.
Now imagine applying this model to mailing lists as well. One could certify threads/messages as 'Intriguing' or 'Fascinating', one could annotate useful threads/messages, much as one can annotate URLs. One could search using a seed person's cert metrics as a search term.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!