The thing that is very frustrating to me about all of these efforts to find a cure for cancer is that they fixate on drugs that can be patented and sold at high prices, or replicating exotic substances from exotic locations. A cure for cancer that is inexpensive and very effective is already known: Curcumin.
Curcumin is the active component of turmeric, the spice that gives curry and old-fashioned mustards that yellow color. And turmeric is not only rather cheap, but the process for extracting and concentrating curcumin has been around for a long time, and cannot be patented and monopolized.
Curcumin induces apoptosis in cancerous cells without harming the healthy cells around them. (Not that Wikipedia is a medical authority, but apparently, this observation has been noted there as well: http://en.wikipedia.org/wiki/Curcumin ) This is something many chemotherapy drugs can't even claim. The mother of a friend of mine was slowly dying from both a metastasized cancer and the chemotherapy she was receiving, which, in theory, was supposed to kill the cancer before it killed her. She then gave up on chemotherapy, and went onto curcumin therapy, taking large doses of concentrated curcumin with piperine (the spice from pepper) to boost absorption (since curcumin doesn't absorb well through the intestines without it). What happened after that was that her health improved, and the cancer was less and less present every time her doctor examined her, and she is still alive today.
One woman's experience with curcumin therapy is described in her cancer blog: Life with Myeloma Here's her account of going onto curcumin therapy.
Right now, the problem for sponsors of cancer research isn't that we don't have any medicines that kill cancer cells without harming healthy cells; their problem is that the medicine that does this won't make them the kind of money they want. Our problem is that without corporate sponsorship, nobody knows about the cures.
The other pair of cancer cures is the combination of inositol hexaphosphate (usually abbreviated as IP6) taken along with inositol; both of these substances are naturally produced by our cells, and cannot be patented. However, the margins of this comment are too small for me to expound on this amazing cure. Google it. ^_~
How about instead of testing IsSecure(), testing HasNoKnownModesOfInsecurity() to sweep for a list of the most common attacks? You can automate that in FP a lot more easily than you can with imperative languages.
I know that at least in Scheme and Lisp, since the syntax is so simple (all the code is just a bunch of nested lists, and nested lists are effectivley trees), code auditing is simply a depth-first-search examination; check each part for known and common attacks.
That's what I mean by automated code auditing. If you can't know that the code itself is totally secure, you can at least know that it contains none of the common known vectors for attacks. This is a lot lower threshold to satisfy than checking for total security, and I suspect in most cases, it is sufficient to defend from all but the most sophisticated attacks.
In FP, as far as I remember, nobody does their own memory allocation, so memory allocation exploits would not be attacking your program, but the implementation of the FP system you're using. If your computational model is purely functional, memory allocation exploits would be pretty much impossible, as far as I understand.
I don't know if this is true in general, but as for buffer overflows, at least in Scheme and Lisp, if you handle input using lists, or even circular or recursive lists (as opposed to arrays that can be overflowed), it is impossible to overflow a buffer to attack other parts of the computer memory. Then, whatever you're going to input that list to (or circular/recursive list) should simply filter and check the input to make sure it is the right domain for the function handling it.
They handle state in a scoped manner that is hard to describe without lots of example code. The best example I can think of is Erlang. If you look at the link I posted above (re-posted for your convenience: http://www.defmacro.org/ramblings/fp.html ) they mention Ericsson inventing the functional language Erlang to handle concurrency.
As for how state functional languages handle state; state is held in the parameters a function is called with. The simplest example is recursion; in an imperative program using a for loop or a while loop or something like that, state is stored in a counter variable that gets incremented or decremented or somehow changed each time the loop is run. In recursion, if the ending condition is not met, the function calls itself with slightly differing parameters; the parameters keep track of the state, but unlike imperative programming, since the parameter is not a variable that can be changed once a call is made, it is impossible to have bugs caused by unexpected or unintentional changes to a variable in the scope of other operations that might change it. FP doesn't permit any declared values to change, so there are no "variables", just constants.
If this makes no sense at all, you'll just have to program a few loops in an imperative language, and a few in a functional language using recursion, and see the difference. It's a lot easier to show interactively than to explain.
If you want to learn about Lambda Calculus (which was developed by Alonzo Church, a contemporary of Allan Turing), Wikipedia is a good place to start (http://en.wikipedia.org/wiki/Lambda_calculus ), but mastering Lambda Calculus is not necessary; first master a functional programming language, and a lot of the lambda calculus will be made easier.
To summarize, here's how you verify with mathematical certainty that a functional program is secure:
You use purely functional code; that guarantees that there are no changes of state involved in the operation of your program.
you unit test each function to make sure that given the correct domain/scope, their return values are always conforming to the desired range (and I don't just mean numbers when I say "range"; I mean correct data formatting, list/tree formatting, data structures, etc.), and you set up input filters that exclude any call parameters that are not part of your desired function domain.
You check to see what functions call which functions, and make sure that they never call a function with parameters that are incorrectly formatted or out of the correct domain
You make sure that every function and every constant is properly scoped.
That's the gist of it. Anything more on this topic, such as automatic code auditing with the certainty of mathematical proofs (by means of lambda calculus proofs) is beyond my expertise. I just know that it's possible to truly secure functional code with mathematical certainty, whereas with imperative code, you can only be sure that your code has not yet failed or exposed a rare bug or failure condition.
If you program using strictly functional programming, you can not only verify that your code is 100% secure, but you can even automate the process. (Preferably in a functional programming language such as Scheme, caml, Haskel, LISP, or Erlang; imperative languages make it very difficult/slow to do with functions what functional languages do very naturally and easily.) Purely functional code can be subjected to automated code auditing easily, whereas code auditing imperative code cannot be guaranteed to catch every bug and unintentionally available abuse.
Here's why, and why just about any computational problem can be solved using FP (functional programming): Functional languages conform to lambda calculus, which has been shown to be Turing equivalent, which means that any program that can be computed on a Turing machine can be solved using Lambda calculus. So long as you program using strictly functions, your program can be verified according to the rules of lambda calculus, and the verification would be as sure as a mathematical proof. This is the only sure way I know of really knowing with mathematical certainty that your application is secure.
Pure functional programming has no assignment statements; there are no state changes for you to keep track of in your program, and in many cases abuses resulting unintended changes of state are the root of security problems. This is not to say that there is no state in functional programming; the state is maintained through function call parameters. (For example, in an imperative programming language, iteration loops keep track of a state variable that guides the running of the loop, whereas a functional program never actually keeps track of state with a variable that changes value; a functional program would carry out iteration by recursion, and the state is simply kept as a parameter passed to each call of the function. No variable with changing state is ever coded.)
Since functional programs lack assignment statements, and assignment statements make up a large fraction of the code in imperative programs, functional programs tend to be a lot shorter for the same problem solved. (I can't give you a hard ratio, but depending on the problem, your code can be up to 90% shorter when described functionally.) Shorter code is easier to debug, which helps in securing code. The reason functional code is so much shorter is that functional programing describes the problem in terms of functions and composition of functions, whereas imperative code describes a step by step solution to the problem. Descriptions of problems in terms of functions tend to be far shorter than algorithmic descriptions of solving them, which is required in imperative code.
Here's the biggest benefit of managing complexity with functional programming: as a coder, you NEVER have to worry about state being messed with. The outcome of each function is always the same so long as the function is called with the same parameters. In imperative programming as done in OOP, you can't depend on that. Unit testing each part doesn't guarantee that your code is bug free and secure because bugs can arise from the interaction of the parts even if every part is tested and passed. In functional programming, however, you never have to deal with that kind of problem because if you test that the range of each function is correct given the proper domain, and pre-screen the parameters being passed to each function to reject any out-of-domain parameters, you can know with certainty where your bugs come from by unit testing each function.
If you need to guarantee the order of evaluation (something that critics of FP advocates sometimes use to dismiss FP advocacy), you can still use FP and benefit: in functional programming, order of evaluation can be enforced using monads. Explaining how is beyond the scope of a mere comment though, but in any case, if you need really reliable code, consider using a functional programming style.
I can't do justice to the matter here; for more information, see th
The first time I read about transparent aluminum being used as armor (face shields) was in popular science, back in the early 1990's. I specifically remembered it being "aluminum oxy nitride". What too them so long?
This variant, found in the fan-mail section of the article's author's original web page, is a superior design, IMHO. It does not require any drilling, and uses an actual camera mounting head from a mono-pod. Yeah, it's more expensive to build, but it's still way cheaper than a comercial stabilizer.
Here's a neat trick that I figured out for building a "honeypot filter" that identifies and blocks all incoming mail that matches the spam harvested in a honeypot e-mail address before any e-mail is delivered to personal mail accounts. Since the honeypot address is used for nothing else but harvesting spam, using the spam received in the honeypot to identify and block incoming spam guarantees that there will be never be false positives (which is more than most filters can say). If the honeypot is being spammed by the worst offenders, you can be sure the spam that is being received there is being sent to millions of others. This honeypot technique is one of the simplest solutions for reliably blocking spam, but it is contingent on having the honeypot being very thoroughly spammed.
So, here's the hack for getting a honeypot address into the databases of real spammers.
First, you need an existing address that is thoroughly infested with spam. If you look at most spams, they usually have some thing at the bottom that says something to the effect of "click here to be removed from our mailing list."
In some of the spams that I've looked at, the link has CGI script variables in the URL. You'll probably see the e-mail address in one of the fields. Replace this e-mail address with the address of the honeypot address, and go to that site.
The page you go to will usually have two options: "remove me from your list" and "Please continue to alert me of special offers". Select the latter, and submit the form. The e-mail address you substituted into the CGI script will probably start receiving spam real soon.
Some spammers will spam you even more if you click on the "remove me" list, because it just proves that the address is live. Before you click on the link, copy it, and edit the field in the CGI script that looks like an e-mail address, substituting the honeypot address for the one in the link. Then, go to the URL and "remove" yourself. You are likely to just start getting spam in the honeypot, especially from unscrupulous spammers.
I don't know why the movie producers chose the name Armegeddon for a movie about an asteroid impact. FYI, "Armegeddon" refers to the bloody battle of the Megiddo vally between the armies of the kings allied with the Antichrist and Jesus (when he comes back), as he lands on the Mount of Olives, just outside of Jerusalem, which is prophecied in the Book of Revelation (a.k.a. the Apocalypse-- Apocalupsis Yohannu is Greek for "the revelation of John").
Revelation 16:16 . . . Then they gathered the kings together to the place that in Hebrew is called Har Mageddon. ..
But as for massive impacts on the earth, I think they would do better to allude to the "second and third trumpets of God's wrath" if they care to make biblical allusions at all:
Revelation 8:8-11 written circa 90 c.e. [my comments in brackets] The second angel sounded his trumpet, and something like a huge mountain, all ablaze, was thrown into the sea. A third of the sea turned into blood, [Perhaps a massive red iron oxide asteroid.] a third of the living creatures in the sea died, and a third of the ships were destroyed.
The third angel sounded his trumpet, and a great star, blazing like a torch, fell from the sky on a third of the rivers and on the springs of water-- the name of the star is Wormwood. [note: in Ukranian, "Chernobyl" = "wormwood"] A third of the waters turned bitter, and many people died from the waters that had become bitter. [Perhaps radioactive contamination from a re-entering Russian satelite bearing nuclear materials salvaged from Chernobyl's remaining facilities.]
Anyhow, just some FYI regarding "Armegeddon."
Something tells me that "second trumpet" won't catch on and replace Armegeddon as the term people allude to when they talk about asteroid strikes. . .
Revelation 13:4-18 Men worshiped the dragon [symbolic of Satan] because he had given authority to the beast [understood to be the Antichrist], and they also worshiped the beast and asked, "Who is like the beast? Who can make war against him?"
The beast was given a mouth to utter proud words and blasphemies and to exercise his authority for forty-two months. He opened his mouth to blaspheme God, and to slander his name and his dwelling place and those who live in heaven. He was given power to make war against the saints [those who follow the Christ] and to conquer them. And he was given authority over every tribe, people, language and nation. All inhabitants of the earth will worship the beast--all whose names have not been written in the book of life belonging to the Lamb that was slain from the creation of the world. [when conferred with other passages, this Lamb is symbolic of Jesus Christ, who was destined to be slain as a propitiation for the sins of humankind in order to reconcile the repentant to God. See Isaiah 53]
He who has an ear, let him hear.
If anyone is to go into captivity,
into captivity he will go.
If anyone is to be killed with the sword,
with the sword he will be killed. This calls for patient endurance and faithfulness on the part of the saints.
Then I saw another beast [the false prophet and sidekick of the Antichrist], coming out of the earth. He had two horns like a lamb, but he spoke like a dragon. He exercised all the authority of the first beast on his behalf, and made the earth and its inhabitants worship the first beast, whose fatal wound had been healed. And he performed great and miraculous signs, even causing fire to come down from heaven to earth in full view of men. Because of the signs he was given power to do on behalf of the first beast, he deceived the inhabitants of the earth. He ordered them to set up an image in honor of the beast who was wounded by the sword and yet lived. He was given power to give breath to the image of the first beast, so that it could speak and cause all who refused to worship the image to be killed. He also forced everyone, small and great, rich and poor, free and slave, to receive a mark on his right hand or on his forehead, so that no one could buy or sell unless he had the mark, which is the name of the beast or the number of his name. This calls for wisdom. If anyone has insight, let him calculate the number of the beast, for it is man's number. His number is 666.
The Jews had a numeration system that gave each letter of their alphabet a number; 1 for aleph, 2 for beth, etc. until the 10th letter, then the 11th letter was assigned the value 20, the next one 30, etc. until you reach 100. The next letter would be valued at 200, etc.
Using this system, the values of the Roman alphabet would be:
If this is indeed the way the prophecy intended for one to calculate the name of the Beast (the Antichrist), some of the names that qualify are:
Fox
Faustin (and all permutations of the letters that form names)
Van Friese (and all permutations of the letters that form names)
A mere bar codes do not qualify as "the number of the beast": the number and the mark of the beast will be imposed on all, as a sign of allegience to the rule of the Antichrist.
To call any other common device or mark the "Mark of the Beast" is to make light of the Mark of the Beast.
My primary reason to have a scheme-shell type interface is that it is consistent. I do plan on having Unix compatability built on as either a layer, or a module.
I didn't intend to have language enforcement, but the best-of-both-worlds scheme/lisp hybrid language that I plan to prepare for HomunculOS (tm) would be natively supported, and would allow EASIER tweaking/personal tuning of the OS, compared to the OS's written in C, like Linux and AtheOS.
What I envisioned was an interface that's like EMACS on steroids. Imagine the power! It's just that some of the commands are counter intuitive. The thing I love about Scheme is that the conventions are somewhat more intuitive than Lisp.
I have been planning on writting a Lisp based OS, but I like Scheme's conventions, and some of it's design features. Unfortunately, there's no complier for Scheme that's fit for the task out there. Do you have any recommendations? is CL fit for the task?
What do you have to say about Lisp OSes? What do you think of the past efforts? I hear that the old Lisp machines (genera, etc.) can do cool things that even modern machines can't do, but I've never heard anything specific. Do you know what these are?
(My OS, HomunculOS (tm), will hopefully have it's own dialect of Lisp (If I can get around to doing this) that is hybridized with the best of Scheme. Modular, capability based, orthogonally persistent, only as much low level coding as necessary, for portability. Scheme shell text interface. )
having the command on the left of the parenthesis is possible with lisp, but would defeat one of the great features of Scheme.
If I'm not mistaken, you mean
defun( . ..)
as opposed to
(defun . ..)
In scheme, the first item in a list can itself be a list. The distinct possibility here is that when the first item is evaluated, the return value may be a procedure, which then operates on the rest of the list.
This would not be possible if the operator were on the outside of the parenthesis. For example,
((operator-maker var1 var2) x y z)
will allow you to construct an operator, and then apply it to x y and z.
Lisp doesn't have this allowance, because variable name space and the function name space are separate, so to call a resultant name as a function, you need to use "funcall"
Slashdot Mirror
The thing that is very frustrating to me about all of these efforts to find a cure for cancer is that they fixate on drugs that can be patented and sold at high prices, or replicating exotic substances from exotic locations. A cure for cancer that is inexpensive and very effective is already known: Curcumin.
Curcumin is the active component of turmeric, the spice that gives curry and old-fashioned mustards that yellow color. And turmeric is not only rather cheap, but the process for extracting and concentrating curcumin has been around for a long time, and cannot be patented and monopolized.
Curcumin induces apoptosis in cancerous cells without harming the healthy cells around them. (Not that Wikipedia is a medical authority, but apparently, this observation has been noted there as well: http://en.wikipedia.org/wiki/Curcumin ) This is something many chemotherapy drugs can't even claim. The mother of a friend of mine was slowly dying from both a metastasized cancer and the chemotherapy she was receiving, which, in theory, was supposed to kill the cancer before it killed her. She then gave up on chemotherapy, and went onto curcumin therapy, taking large doses of concentrated curcumin with piperine (the spice from pepper) to boost absorption (since curcumin doesn't absorb well through the intestines without it). What happened after that was that her health improved, and the cancer was less and less present every time her doctor examined her, and she is still alive today.
One woman's experience with curcumin therapy is described in her cancer blog: Life with Myeloma
Here's her account of going onto curcumin therapy.
Right now, the problem for sponsors of cancer research isn't that we don't have any medicines that kill cancer cells without harming healthy cells; their problem is that the medicine that does this won't make them the kind of money they want. Our problem is that without corporate sponsorship, nobody knows about the cures.
The other pair of cancer cures is the combination of inositol hexaphosphate (usually abbreviated as IP6) taken along with inositol; both of these substances are naturally produced by our cells, and cannot be patented. However, the margins of this comment are too small for me to expound on this amazing cure. Google it. ^_~
How about instead of testing IsSecure(), testing HasNoKnownModesOfInsecurity() to sweep for a list of the most common attacks? You can automate that in FP a lot more easily than you can with imperative languages.
I know that at least in Scheme and Lisp, since the syntax is so simple (all the code is just a bunch of nested lists, and nested lists are effectivley trees), code auditing is simply a depth-first-search examination; check each part for known and common attacks.
That's what I mean by automated code auditing. If you can't know that the code itself is totally secure, you can at least know that it contains none of the common known vectors for attacks. This is a lot lower threshold to satisfy than checking for total security, and I suspect in most cases, it is sufficient to defend from all but the most sophisticated attacks.
In FP, as far as I remember, nobody does their own memory allocation, so memory allocation exploits would not be attacking your program, but the implementation of the FP system you're using. If your computational model is purely functional, memory allocation exploits would be pretty much impossible, as far as I understand.
I don't know if this is true in general, but as for buffer overflows, at least in Scheme and Lisp, if you handle input using lists, or even circular or recursive lists (as opposed to arrays that can be overflowed), it is impossible to overflow a buffer to attack other parts of the computer memory. Then, whatever you're going to input that list to (or circular/recursive list) should simply filter and check the input to make sure it is the right domain for the function handling it.
They handle state in a scoped manner that is hard to describe without lots of example code. The best example I can think of is Erlang. If you look at the link I posted above (re-posted for your convenience: http://www.defmacro.org/ramblings/fp.html ) they mention Ericsson inventing the functional language Erlang to handle concurrency.
As for how state functional languages handle state; state is held in the parameters a function is called with. The simplest example is recursion; in an imperative program using a for loop or a while loop or something like that, state is stored in a counter variable that gets incremented or decremented or somehow changed each time the loop is run. In recursion, if the ending condition is not met, the function calls itself with slightly differing parameters; the parameters keep track of the state, but unlike imperative programming, since the parameter is not a variable that can be changed once a call is made, it is impossible to have bugs caused by unexpected or unintentional changes to a variable in the scope of other operations that might change it. FP doesn't permit any declared values to change, so there are no "variables", just constants.
If this makes no sense at all, you'll just have to program a few loops in an imperative language, and a few in a functional language using recursion, and see the difference. It's a lot easier to show interactively than to explain.
To summarize, here's how you verify with mathematical certainty that a functional program is secure:
That's the gist of it. Anything more on this topic, such as automatic code auditing with the certainty of mathematical proofs (by means of lambda calculus proofs) is beyond my expertise. I just know that it's possible to truly secure functional code with mathematical certainty, whereas with imperative code, you can only be sure that your code has not yet failed or exposed a rare bug or failure condition.
If you program using strictly functional programming, you can not only verify that your code is 100% secure, but you can even automate the process. (Preferably in a functional programming language such as Scheme, caml, Haskel, LISP, or Erlang; imperative languages make it very difficult/slow to do with functions what functional languages do very naturally and easily.) Purely functional code can be subjected to automated code auditing easily, whereas code auditing imperative code cannot be guaranteed to catch every bug and unintentionally available abuse.
Here's why, and why just about any computational problem can be solved using FP (functional programming):
Functional languages conform to lambda calculus, which has been shown to be Turing equivalent, which means that any program that can be computed on a Turing machine can be solved using Lambda calculus. So long as you program using strictly functions, your program can be verified according to the rules of lambda calculus, and the verification would be as sure as a mathematical proof. This is the only sure way I know of really knowing with mathematical certainty that your application is secure.
Pure functional programming has no assignment statements; there are no state changes for you to keep track of in your program, and in many cases abuses resulting unintended changes of state are the root of security problems. This is not to say that there is no state in functional programming; the state is maintained through function call parameters. (For example, in an imperative programming language, iteration loops keep track of a state variable that guides the running of the loop, whereas a functional program never actually keeps track of state with a variable that changes value; a functional program would carry out iteration by recursion, and the state is simply kept as a parameter passed to each call of the function. No variable with changing state is ever coded.)
Since functional programs lack assignment statements, and assignment statements make up a large fraction of the code in imperative programs, functional programs tend to be a lot shorter for the same problem solved. (I can't give you a hard ratio, but depending on the problem, your code can be up to 90% shorter when described functionally.) Shorter code is easier to debug, which helps in securing code. The reason functional code is so much shorter is that functional programing describes the problem in terms of functions and composition of functions, whereas imperative code describes a step by step solution to the problem. Descriptions of problems in terms of functions tend to be far shorter than algorithmic descriptions of solving them, which is required in imperative code.
Here's the biggest benefit of managing complexity with functional programming: as a coder, you NEVER have to worry about state being messed with. The outcome of each function is always the same so long as the function is called with the same parameters. In imperative programming as done in OOP, you can't depend on that. Unit testing each part doesn't guarantee that your code is bug free and secure because bugs can arise from the interaction of the parts even if every part is tested and passed. In functional programming, however, you never have to deal with that kind of problem because if you test that the range of each function is correct given the proper domain, and pre-screen the parameters being passed to each function to reject any out-of-domain parameters, you can know with certainty where your bugs come from by unit testing each function.
If you need to guarantee the order of evaluation (something that critics of FP advocates sometimes use to dismiss FP advocacy), you can still use FP and benefit: in functional programming, order of evaluation can be enforced using monads. Explaining how is beyond the scope of a mere comment though, but in any case, if you need really reliable code, consider using a functional programming style.
I can't do justice to the matter here; for more information, see th
The first time I read about transparent aluminum being used as armor (face shields) was in popular science, back in the early 1990's. I specifically remembered it being "aluminum oxy nitride". What too them so long?
This variant, found in the fan-mail section of the article's author's original web page, is a superior design, IMHO. It does not require any drilling, and uses an actual camera mounting head from a mono-pod. Yeah, it's more expensive to build, but it's still way cheaper than a comercial stabilizer.
Here's a schematic of the improved design. (PDF file)
Here's a neat trick that I figured out for building a "honeypot filter" that identifies and blocks all incoming mail that matches the spam harvested in a honeypot e-mail address before any e-mail is delivered to personal mail accounts. Since the honeypot address is used for nothing else but harvesting spam, using the spam received in the honeypot to identify and block incoming spam guarantees that there will be never be false positives (which is more than most filters can say). If the honeypot is being spammed by the worst offenders, you can be sure the spam that is being received there is being sent to millions of others. This honeypot technique is one of the simplest solutions for reliably blocking spam, but it is contingent on having the honeypot being very thoroughly spammed.
So, here's the hack for getting a honeypot address into the databases of real spammers.
First, you need an existing address that is thoroughly infested with spam. If you look at most spams, they usually have some thing at the bottom that says something to the effect of "click here to be removed from our mailing list."
In some of the spams that I've looked at, the link has CGI script variables in the URL. You'll probably see the e-mail address in one of the fields. Replace this e-mail address with the address of the honeypot address, and go to that site.
The page you go to will usually have two options: "remove me from your list" and "Please continue to alert me of special offers". Select the latter, and submit the form. The e-mail address you substituted into the CGI script will probably start receiving spam real soon.
Some spammers will spam you even more if you click on the "remove me" list, because it just proves that the address is live. Before you click on the link, copy it, and edit the field in the CGI script that looks like an e-mail address, substituting the honeypot address for the one in the link. Then, go to the URL and "remove" yourself. You are likely to just start getting spam in the honeypot, especially from unscrupulous spammers.
ToastedSpam.com has a page called Free spam! that has a massive list of web sites where you can sign up for spam.
Something tells me that "second trumpet" won't catch on and replace Armegeddon as the term people allude to when they talk about asteroid strikes. . .
The Jews had a numeration system that gave each letter of their alphabet a number; 1 for aleph, 2 for beth, etc. until the 10th letter, then the 11th letter was assigned the value 20, the next one 30, etc. until you reach 100. The next letter would be valued at 200, etc.
Using this system, the values of the Roman alphabet would be:
A=1; B=2; C=3; D=4; E=5; F=6; G=7; H=8; I=9;
J=10; K=20; L=30; M=40; N=50; O=60; P=70; Q=80; R=90;
S=100; T=200; U=300; V=400; W=500; X=600; Y=700; Z=800;
If this is indeed the way the prophecy intended for one to calculate the name of the Beast (the Antichrist), some of the names that qualify are:
A mere bar codes do not qualify as "the number of the beast": the number and the mark of the beast will be imposed on all, as a sign of allegience to the rule of the Antichrist.
To call any other common device or mark the "Mark of the Beast" is to make light of the Mark of the Beast.
The LispOS mailing list was the first place I looked. My design principle can be summarized as KISS aSS:
:o)
Keep It Stable, Secure, and Small/Simple
j/k
.
My primary reason to have a scheme-shell type interface is that it is consistent. I do plan on having Unix compatability built on as either a layer, or a module.
I didn't intend to have language enforcement, but the best-of-both-worlds scheme/lisp hybrid language that I plan to prepare for HomunculOS (tm) would be natively supported, and would allow EASIER tweaking/personal tuning of the OS, compared to the OS's written in C, like Linux and AtheOS.
What I envisioned was an interface that's like EMACS on steroids. Imagine the power! It's just that some of the commands are counter intuitive. The thing I love about Scheme is that the conventions are somewhat more intuitive than Lisp.
Let me know what you think. . .
I have been planning on writting a Lisp based OS, but I like Scheme's conventions, and some of it's design features. Unfortunately, there's no complier for Scheme that's fit for the task out there. Do you have any recommendations? is CL fit for the task?
What do you have to say about Lisp OSes? What do you think of the past efforts? I hear that the old Lisp machines (genera, etc.) can do cool things that even modern machines can't do, but I've never heard anything specific. Do you know what these are?
(My OS, HomunculOS (tm), will hopefully have it's own dialect of Lisp (If I can get around to doing this) that is hybridized with the best of Scheme. Modular, capability based, orthogonally persistent, only as much low level coding as necessary, for portability. Scheme shell text interface. )
having the command on the left of the parenthesis is possible with lisp, but would defeat one of the great features of Scheme.
.)
.)
If I'm not mistaken, you mean
defun( . .
as opposed to
(defun . .
In scheme, the first item in a list can itself be a list. The distinct possibility here is that when the first item is evaluated, the return value may be a procedure, which then operates on the rest of the list.
This would not be possible if the operator were on the outside of the parenthesis. For example,
((operator-maker var1 var2) x y z)
will allow you to construct an operator, and then apply it to x y and z.
Lisp doesn't have this allowance, because variable name space and the function name space are separate, so to call a resultant name as a function, you need to use "funcall"