I found that the combination of a large hamster wheel and a good supply of interns keeps the power running quite steadily. Or at least, as long as the food pellets hold out.
Which appreciates much more quickly and reliably than gold, and whose price the US government is clearly willing to dedicate considerable resources to maintaining.
(Only Zuul)
"Indie" status doesn't actually matter that much in the publishing pipeline; you can submit your paper to a journal in the same way that anybody else does, and it will get the same consideration. (The place where organization status matters a bit more is at the reverse end -- if one of the authors is particularly well-known, that tends to make the review process easier)
If your project has practical applications and you wish to patent, make sure to file that first. In that case, consult with a patent attorney on the right things to do next.
Otherwise, pick the appropriate journal and submit following the guidelines on their web page. You'll definitely want to format your paper in LaTeX, since pretty much everyone requires that; some journals have standard LaTeX style packages they want you to use, but these are easy to plug in. (e.g., the Physical Review uses revtex.sty, and many other journals now use it too)
As far as which journal you want, it depends on the particular field, but I'm guessing that Science isn't it -- that's a very high-profile journal which is intended to be things of interest to the scientific community at large, but in practice it has a fairly strong bio/chemistry/some physics focus. Someone else on this thread may have particular journal suggestions, or you may want to search on-line for similar (recent) papers and see where they were published. ACM transactions are often good "default" places in CS. Also, CS tends to prefer conference talks to straight-up journal publications; you may consider submitting your algorithm as a talk to some appropriate CS conference, in which case the article is published as part of the proceedings. Again, the conference depends on your particular subject.
Don't worry about your lack of organizational affiliation. That's rarely a big issue.
Speaking as someone who writes performance-critical very-large-scale applications, the idea sounds just as nuts in that world. A 20% speedup in malloc is worth, at the most, a 2% speedup in the overall process. (If you're spending more than 10% of time in malloc, perhaps you should be using a freelist, arena, *anything* else?) Wasting an entire core for a 2% speedup doesn't seem horribly efficient to me.
Also, I can't help noticing that most of their argument for speed starts from the hypothesis that an uncontended mutex lock takes about as long as a single-threaded malloc. That makes me wonder what the hell kind of locking implementation they're using for their design, and whether their time wouldn't be better spent improving *that*.
Are you sure that the error messages are even meaningful in Korean?
Really, I would say that flapping one's wings and/or being hurled from a catapult or similar device would count as well.
>140: The special EMACS model, with five extra modifiers key, twelve pedals, and a steam release valve.
And I should say, I'm certainly not saying that nobody should run their own DNS server. Just that for most people, it's not worth the effort.
The enormous amount of extra work is in maintaining a Linux server in the first place. (And in learning enough about it for "just editing a config file" to be a small matter, etc)
Slashdot norms to the contrary, most people don't do this.
Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.