Slashdot Mirror

http://www.weizmann.ac.il/ESER/People/Karni/resear ch.html has some information about it.

It doesn't exist!

Moti Milgrom proposed MOND:MOdified Newtonian Dynamics, which seems to do a much better job at describing large scale gravitational dynamics than dark matter...I watched the data come in sitting at the console of the VLT, and I also watched Nature reject the paper because alot of careers are riding on dark matter being real...

The best 3D reconstruction method know so far is described in: http://www.wisdom.weizmann.ac.il/~wexler/papers/ic cv03.html

If you really need speed, you can use RC4 securely but you have to know what you are doing and be aware of these attacks so you can employ protective countermeasures. Otherwise you are better off to use a cipher like AES which is actually secure.

I create graphs using Grace to put into LaTeX documents and anywhere else. IMHO, its quality is among the best; exports PS, EPS, PDF, MIF, etc.

LaTeX can't be beat for mathematics and quality type-setting. Plus, the input files are good for decades.

Its only shortcoming, for me, is that it gets ponderous for preparing highly visual presentations with drawings, boxes, etc.

One of these years I'd like to see an SVG based authoring tool that, for MathML rendering, used TeX as the underlying engine just for little boxes of equations (ignoring the multi-page layout) and paragraphs.

High quality math typesetting, with scalable vector graphics, in an open XML language, on the web, would be the ultimate in expression.

I'd dump my word processor and presentation software in a millisecond and just use such a tool.

Other tools which I have come across, but haven't really worked with: Axiom (symbolic computations, CAS); Scigraphica (graphing); opendx (data explorer + visualization).

I've actually never really used R (by the time I came across it, I was done with my physics labs), so I can't really compare any of the others to it. But it definitely looks like one of the tools that I should add to my suite.

Wrong. I've read Jay Beale's paper, and he argues that while "security implemented solely through obscurity is bad", obscurity can be a useful extra layer to improve security. But "security implemented solely through obscurity" is precisely what is happening in the ICC case, and a little reverse engineering renders the system completely defenseless. The theoretical reason why the reverse engg. was inevitable is the impossibility of obfuscating programs.

Not that Excel has any graphing capability worth shit either, for that matter.

Personally, I use mainly R, and sometimes Grace when I want a nice and simple to use GUI thingy.

(I'm a co-author of the presentation.)

The web page was extended to include a FAQ discussing the issues brought up here.

You mean something based on this ?

Full Text of the Nature article (without the ridiculous Nature subscription price)

Links to associated material here

Full Text of the Nature article (without the ridiculous Nature subscription price)

Links to associated material here

Full Text of the Nature article (without the ridiculous Nature subscription price)

Links to associated material here

Life would be so much easier if we could just look at the source code...

(What you really meant was if we could understand the damn thing, too. At long last. Biochemists are obviously just lazy. :-)

Anyway, I agree -- the world would be a better place with Stevens still in it, writing books.

While I agree that the Motif app looks a little outdated, the app is free as in GPL and is really powerful in terms of features. For example, it allows scripting.

For (almost as) quick and better looking plots than gnuplot does check out grace. X interface, more goodies, etc. GPL too, since people were complaining about gnuplot's license. So maybe the last part (is reasonably priced and is hard to beat) is less compelling as you thought ^_^

(however, nothing beats gnuplot when it comes to very simple one-line-almost-no-data-manipulation plots)

While I'm always glad to see progress on every front, gnuplot has been sitting on the 3.* level for a long time. I had the idea that the original authors left without properly designating heirs.

The SVG device driver support is intriguing, but being a "Gnu" thing it doesn't take advantage of the extensive plotutils library that, sadly, seems to have experience strong development only up to a point.

Anyway, for people interested in doing serious xy 2D scientific plots, you owe it to yourself to checkout Grace.

Everyone always raves about 3D, volume rendering and stereoscopic movies, but so much importance science gets done in plain old 2D xy plots.

If they don't, what is the preferred technique for diagramming an OOP program?

The fallacy in this article is the assumption that NGSCB is perfectly secure and unbeatable. This isn't the case, and in fact there are reasons to believe that at least some of its functions are theoretically impossible.

NGSCB can be broken; you'll just have to go through a lot of trouble to do so (scrape off chip packaging and decode its internals without triggering intrusion detectors, etc.). This is sufficient to stop casual copyright infringement, or to keep your workers at check. But one ought to doubt if the expense of breaking NGSCB isn't worthwhile for online gambling, elections or other applications where the incentives are very high.

Read on for examples of what bobej means.

So, what does "bobej" mean? I couldn't find any clarification on a Google search. "jebob" returned a cute baby, but I don't think he's posting on Slashdot yet.

Inquiring minds want to know! And they have karma to burn!

I wouldn't be the least bit surprised if it was software that caused the vehicles to become disabled.

I'm reminded of the software bug that destroyed a very expensive Ariane rocket. Both guidance computers essentially bluescreened and the main computer used the error code as it had other values.

Official ESA account of the Ariane 5 Flight 501 (1996) failure
Three page report of "The Bug That Destoyed a Rocket" [pdf]

Calm down, killer. Microsoft's not THAT smart.

It Is Not A Big Secret

At worst, I suppose Microsoft could make it's own scheme and try to push other people out, but I doubt that there are enough Microsoft MTAs out there to make that sort of system survive. If they implemented it for Microsoft-only, they'd almost have to give the option to revert to a traditional white-list when the sender can't play Microsoft's Holy Encryption Puzzle. After all. If you send someone an e-mail and outlook Express won't give it to them, just tell them that - Outlook Express won't let you look at it. I sent it, sorry. The problem is clearly on your end, call support for help.

Microsoft HATES support costs and one thing you don't do on Windows is screw with grandma's emails.

Don't take my word for it...

read the paper yourself!

Tom

One of the earliest computers around was WEIZAC (picture here).
Not much to say about it.

This has actually happened. Alexander Flemming refused to patent penicillin [...] The result was that nobody worked on making penicillin available in commercial quantities, because there was no money to be made doing so. This only changed when the military funded development in the early days of WW II. So Flemming's life-saving discovery went unused for more than a decade, because he wasn't greedy.


Can you provide any corroboration for that? As recalled by E.B.Chain, who first isolated the ctive penicillin, and subsequently was a co-recipient, with Fleming, of the Nobel Prize, it simply wasn't clear to anyone in 1928 that penicillin would have drug qualities. Chain claims that his motivation for isolating it came from his biochemical research, not as a drug. He doesn't mention military funding either.

So, maybe, greed is not good?

I can't remember who wrote the statistics add-ins for Excel (and I don't have a Windoze computer handy to find out) but that is one thing that would be very useful to me. Plus there is a range of plotting functions that are simply not there in Gnumeric, and I've been struggling along with Grace, which has a bit of a slow learning curve.. For all that, though, Gnumeric's a great product.

There are bacteria living in the "Dead Sea" as well (see here).

See also here for a discussion of bacteria living in salt-saturated solutions (the main discussion is about spore survival in salt inclusions--for about 250 million years!).

Hey, and maybe we will see people floating in Europa's oceans as well :-)

I agree that OpenOffice is probably the equal of MSOrifice as far as general usability is concerned (I use it every day) but from my point of view, OO needs serious beefing up in statistics and plotting for the spreadsheet to be very useful to me. I've been sort of getting by with Grace, but that seems to have a bit of a long learning curve for me. Now if anybody knows of a good equivalent of SPSS for Linux (instant Score: 5: Informative, anyone?), I'll be a happy man. Dammit, I would even pay for it if it's affordable on a student budget...

Don't use gnuplot. Use Grace. It can be scripted and is much more powerful and flexible.

Dark Matter isn't the only explanation for Fritz Zwicky's 1993 observation.

MOND or Modified Newtonian Dynamics proposed by Moti Milgrom is I think better. If I were to bet on someone winning a future Nobel, Milgrom would be the person.

I'm driving the VLT as I type this...sentence was interrupted for a preset...I'm back now.

Anyway, I know a number of scientists that seriously consider the Newton's may not work at large scales. Nature recently rejected a paper from some rather prominent that seemed to confirm that gravity behaves differently at large scales. But, science is very reluctant to change its equations and publication will have to await more data.

Just remember - Dark matter may not exist. Be skeptical of those who treat it as fact.

MOND FAQ

Dark-Matter Heretic [This is a wonderful article]

Excuse me, hardgrok, but you might say my PhD in Computer Science is kind of a "formal CS background." I learned about FSA in my algorithms class both as an undergrad and grad student, and I can clearly see that statecharts are not the same thing by any means. I find that people who make the comments like you made really haven't taken any time to read about statecharts, or perhaps have seen them in expensive tools and dismissed them as just something else to learn and not worthwhile. A lot of times, people dismiss them because they have not seen good examples of their use.

I'd strongly suggest you read Ian Horrocks' book about using statecharts for user interface design (Constructing the User Interface with Statecharts), or Miro Samek's book on embedded systems, or my book on simulation construction with statecharts ("Flash MX for Interactive Simulation"). You will see that much traditional software, made by people with more than enough CS background to go around, in many cases still suffers from design problems. Horrocks has a great example of problems with the Visual Basic calculator that comes with Windows, and Samek has a great example (Therac-25) of a therapeutic medical device that killed people because of programming design flaws.

If you're looking for something on the web to preview, I would suggest reading David Harel's original 1987 paper that started things out (http://www.wisdom.weizmann.ac.il/%7Eharel/SCANNED .PAPERS/Statecharts.pdf), or you can look at some references I have from my web site (http://www.flashsim.com/flash_resources-uml.html# state).

-jonathan

He is an ACM Fellow, whose citation reads

For his fundamental work in various areas of theoretical science, his invention of the visual language of statecharts for specifying reactive systems, and his expository contributions, especially via the widely acclaimed 1987 book "Algorithmics, the Spirit of Computing".

Try again. It's not a PDA. Here's the original TR by Harel, who developed the concept:

Statecharts.pdf

many of the links between cigarettes and diseases are just that: links. Yet to be proven.

What would constitute "proof" for you? Would the stuff mentioned in this column, such as

The tide turned in 1998. Scientists studying a tumor suppressor gene called p53 demonstrated a direct link between cigarettes and lung cancer. p53 is the cell's error-detecting system, proofreading the DNA before cell division to make sure there is no damage. When it detects DNA damage, p53 halts cell division and stimulates DNA repair enzymes that fix the trouble. Mutations that inactivate p53 remove a key barrier to unrestricted cell division. p53 is inactivated in 70% of all lung cancers. A puzzling discovery was that the p53 mutations in cancer cells almost all occur at one of three "hot spots" within the p53 gene.

The key link that explains the "hot spots" and links lung cancer to cigarettes is a chemical called benzo (a) pyrene (BP), a potent mutagen released into cigarette smoke from tars in the tobacco. The epithelial cells of the lung absorb BP from cigarette smoke and chemically alter it to a derivative form, benzo (a) pyrene diol epoxide (BPDE). BPDE binds directly to the tumor suppressor gene p53 and mutates it to an inactive form. The key evidence linking cigarette smoking and cancer, the "smoking gun," is that when the mutations of p53 caused by BPDE from cigarettes were examined, they were found to cluster at precisely the same three specific "hot spots" seen in lung cancers! The conclusion is inescapable: the mutations inducing lung cancer are caused by chemicals in cigarette smoke.

be sufficient?

For example: how can scientists say that they don't know what causes cancer and then turn around and say cigarettes cause lung cancer?

Where has a particular scientist said both that they don't know what causes cancer and that cigarettes cause lung cancer? (Scientist A saying that we don't know what causes cancer, and scientist B saying that cigarettes are a cause of lung cancer, doesn't count.)

In fact, where has any scientist said that we don't know what causes cancer?

IF they really knew what causes cancer, they'd be very close to a cure.

No, they wouldn't necessarily be very close to a cure. Knowing the cause of a disease doesn't mean that it's easy to eliminate that cause. Just because a defective version of the BRCA1 gene strongly predisposes women to breast cancer, that doesn't necessarily mean you can easily just go in and fix that gene.

Furthermore, there might not be a cause for some disease; there does not appear to be one single magic cause for cancer - it appears that various environmental causes can cause various cancers, as can various genetic problems.

This is very serious, and the answer is "you can't". You *could*, however, make it strong enough that terrorist attacks or earthquakes were unlikely to knock the thing down.

For this very reason, I suggest building bottom up. That is, start by building towers in a bunch of regions, and use the towers to launch rockets.

This *can* be done if the compressive-to-tensile strength ratios approach one. Indeed, looking here or here (for pdf), we see that this is likely the case, as long as your purity is pretty good.

Such a bottom-up construction has several advantages: (1) less likely to suffer a catastrophic failure. (2) thickest at the ground, where terrorist attack is more possible (3) economic advantage to the company that constructs it *before* the project is complete, because there are huge weight savings to be had launching your rockets from even an altitude of 10 km -- so you get customers from the getgo (4) you get to test the things out extensively (5) you end up with an ideal latch-on point for the space elevator when you *do* construct it (6) you end up with a cheaper space elevator to boot, because you're launching your materials from a much higher location. (7) You have one heck of a tourist resort even before you get into space: "Hotel in the sky" whenver launches aren't being carried out.

Lisp has one of the best object-oriented paradigm implementation, Meta-Object Protocol among languages with both scripting and bytecompiling capabilities.

Scheme has been proved as a good language for GUI and configuration: GIMP, Sawfish, TeXmacs.

OCaml has all the power as Lips, just in syntax conviniect for many Java/C-poisoned brains to read faster. No wonder there are many real-world applications on it.

Haskell... I just love how it demonstrates that OOP is not everything (and even not enough) :)

Sun works for telecom industry - why not consider Erlang?

And don't ignore Mozart - it's multi-paradigm pradigm might be just what we all will thing as the best in 3-5 years.

The list is not complete, of course. And it's inspired by Functional Programming.

My main point here is: each of above languages, would it be in hands of Sun marketed instead of Java (with all that money invested to), would have quality of implementation much better than Java.

In fact, I am impressed how such poorly designed language as Java succeed so far on the market. It wouldn't without so much money behind. And without so many classes written by Sun to compensate the poor design of the core language itself.

Would Sun invest so much efforts and money to FP language then the result would be much better. Because quality is why FP matters.

The version currently circulating is indeed a draft. The final version, when available, will be placed at my homepage, and specifically here.

-- Eran Tromer

The version currently circulating is indeed a draft. The final version, when available, will be placed at my homepage, and specifically here.

-- Eran Tromer

> because OpenOffice doesn't do something as fscking simple as a polynomial regression

Grace would be a less drastic solution. :)

Not to mention Octave, which might be a little bit too complex for this matter. Here, the function for squares polynomial regression polyfit

More details here. This has become a frosh rite of passage for CSE's, i.e., to read this case.

I think the sad thing is how much FUD there is about these technologies. Palladium, LaGrande, TCPA, and the like are NOT limiting technologies. All software that runs on non-Palladium systems will run on Palladium enabled hardware (like Intel's LaGrande). These technologies give developers more tools to protect data (something that is impossible without hardware support).

how little control or privacy these projects will leave us

The control still remains with the end user. By design, the user determines what is trusted and what is not trusted. And privacy is always protected, and that protection is backed by hardware.

These projects will not give us more stable software, just buggy software that will let us do less

I'm not sure where you are coming with that. Palladium will make it easier to develop secure applications- reduced complexity correlates directly with reduced bugs.

Basically, Palladium sets out to solve the problem of protecting mobile code from a malicious host (that is, it protects software from software). Without hardware support, developers must rely on obfuscation or tamper-resistant code to completely protect their code and data (something which is provably impossible to do, btw).

I totally agree statecharts is the way to go for designing UI with even a little complexity. David Harels's (the father of statecharts)original paper [pdf]on statecharts is very nice and concise intro to state charts and since state charts are now a part of UML a lot of UML books cover the semantics of designing with statecharts as well.

nothing could possibly go faster than an electron zipping through silicon at absolute zero...

Wow, normally people assume I'm a moron, but this response really takes the cake!

Do you really think I thought 24fps movie could be expanded to 60? Didn't it occur to you that I meant that using digital technology movies could be captured at 60fps like they are with both HDTV and even NTSC? I mean seriously, why would you think that I meant converting old movies from 24 fps to 60? Didn't the fact that I mentioned a specific # of FPS to begin with clue you in to the idea that I might already know that about movies? Failing that, everybody knows that old movies wouldn't be reshown in theaters. At best I could catch these magically expanded movies on TV, negating the need to go find a digital theater to see them on. I think this is the stupidest that anybody has ever assumed that I am. heh.

Just so you know, it is possible to expand 24 fps video to 60 fps through interpolation.

There are products on the market today designed for interpolating the in-between frames of video for smoothing out slow motion sequences. Frankly, it'd be easy to use this to increase the frame rate of a video like you suggested I meant. It wouldn't be as accurate as simply filming at 60 fps, but it would certainly look smoother.

"Why shoot things at 60fps when you're going to either more than double your film costs or have something that has to be downsampled for everyone else?"

Becuse there is no film? With digital techonlogy, it's simply a matter of capacity. I don't know if you've heard about it or not, but HDTV is going to support the resolution of 1920 by 1090 (or some resolution like that) @ 60fps. Seeing as how this resolution exceeds what's being shown digitally today it's a safe bet that the technology is there to make full length movies at 60fps.

As for the benefit of it: Ebert had an opportunity to sample footage shot on a camera running at 48fps. He was extremely pleased with how much smoother the video was. The example he used was a moving truck drove by. In the 24 FPS version, he couldn't read the name on the side of the truck. At 48 it became clear.

It's not a question of if, rather a question of when. One day movies will be captured and shown at 60fps.

> but does it look pretty?
I'd say it does:
a color-coded simulation of the mesh routing algorithm (16MB)

Done: here is the proof. Be warned, though: it's highly technical.

...but I do not think that perl is the "Write Once, Read Nowhere" langue you make it out to be ^_^

Just for a little fun, I thought I'd try out my rusting perl tricks and unroll your silly script.

$c = 'plfeY04jaJnYI';
$s = substr $c, 0, 2;
for $l (1..8) {
for ('a' x $l .. 'z' x $l){
if($c eq crypt($_, $s)) {
print "$_.$s\n";
exit;
}
}
}

If you want to see a really good password cracking program, check out Alec Muffett's great and famous Crack. It's really great, especially when you have good dictionaries. If you want to check if your password is easily cracked by Crack, you can use Alec Muffett's CrackLib. Check out my online Password-Guessability-O-Meter, I wrote it some time ago to demonstrate to one of my clients how does the CrackLib work. You just enter your desired password, and it tells you if (and why) it is easy to guess, using English, Polish, Czech, French and Latin dictionaries.

I use CrackLib for online registrations CGI scripts etc. so users can't have silly and easy to guess passwords. It can also be used with passwd program. Great library, and easy to use (there's Crypt::Cracklib Perl interface), but may be quite difficult to set up for the first time.

Not very difficile, Mister shiny@rfl.pl, but I shall compliment you for at least trying to obfuscate with the silly "q//" perl operateur ^_^

$q=q,p,.q,l,.q,f,.q,e,.q,Y,.q,0,.q,4,.q,j,.q,a,.q, J,.q,n,.q,Y,.q,I,;

The "if" statement is another ruse; suffixed "if" is in fact called before the condition of the "if" statement, and he uses this to initialise $q apparently after it's been first used. The above code is in fact equal to this:

$q = 'plfeY04jaJnYI';
$x = substr $q, 0, 2;

And it makes itself apparent that $q is the crypt hash (henceforth called $crypt) and $x is the salt ($salt).

for (++$_..$_<<3){...}

Now you are just being silly :-) $_ is not used yet and thus is 0, and ++0 is of course 1. 1<<3 is 8.

for($i = 1; $i <= 8; ++$i) {...}

Which not only looks simpler, but runs faster too ^_^

I just run this benchmark:

#!/usr/bin/perl -w

use Benchmark;

sub s1{ for ($i = 1; $i <= 1_000_000; ++$i) { } }
sub s2{ for (1 .. 1_000_000) { } }

$t1 = timestr timeit 100, \
$t2 = timestr timeit 100, \

print "1. $t1\n2. $t2\n";

1. 103 wallclock secs (87.77 usr + 0.15 sys = 87.92 CPU) @ 1.14/s (n=100)
2. 60 wallclock secs (51.93 usr + 0.04 sys = 51.97 CPU) @ 1.92/s (n=100)

But in my code this loop has only eight iterations, where the 8th one takes two years, so the loop control overhead itself doesn't really matter here. The inner loop is more important but crack() function takes most of the time, anyway.

Older versions of Perl (I don't know which exactly) created a temporary array for the range operator in foreach loop, so the code like:

for (1 .. 1_000_000_000) { ... }

The "and die" bit just is taking advantage of the short-circuit boolean operateur système. The "die" only is executing when $crypt (the origin hash) and the encrypted form of the current guess are equal, in which case the key has been found and we quit ^_^ I changed it to a nicer looking "print" statement for further clairitie.

I think you're very good, really. Most of people have no idea how to analyze such obfuscated code. Actually I'm quite disappointed that decrypting my code was so easy for you... :)

I'll tell you why and how I wrote this program. I was inspired by this code:

#!/usr/bin/perl
@a=(Lbzjoftt,Inqbujfodf,
Hvcsjt); $b="Lbssz Wbmm"
;$b =~ y/b-z/a-z/ ; $c =
" Tif ". @a ." hsfbu wj"
."suvft pg b qsphsbnnfs"
. ":\n";$c =~y/b-y/a-z/;
print"\n\n$c ";for($i=0;
$i<@a; $i++) { $a[$i] =~
y/b-y/a-z/;if($a[$i]eq$a
[-1]){print"and $a[$i]."
;}else{ print"$a[$i], ";
}}print"\n\t\t--$b\n\n";

So I wrote the first working version and started to make it as small as possible. Originally it didn't have to be obfuscated, just small. This is the smallest version I've written so far:

$c='plfeY04jaJnYI';$s=substr$c,0,
2;for(1..8){for('a'x$_..'z'x$_){
die"$_.$s\n"if crypt($_,$s)eq$c}}

$c='plfeY04jaJnYI';$s=substr$c,
0,2;for(1..8){$c eq crypt$_,$s
and die"$_.$s"for'a'x$_..'z'x$_}

$c='plfeY04jaJnYI';$s=substr$c,0,2;$k=
'a';$k++while$c ne crypt$k,$s;die"$k.$s";

Hopefully that wasn't too difficile to follow, my english is not perfect.

Just remember, Mr. shiny@rfl.pl, no langue is completely impenetrable (except perhaps Intercal, but that's a small bit pathological :-)

This Unlambda program "calculates and prints the Fibonacci numbers (as lines of asterisks)":

```s``s``sii`ki
`k.*``s``s`ks
``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
`k``s`ksk

I wanted to show a Hello world example of Brainf***, but I got this error:

Lameness filter encountered. Post aborted!
Reason: Please use fewer 'junk' characters.

You like Perl, so if you know Inline::C and Inline::CPR (if you don't, read Pathologically Polluting Perl by Brian Ingerson) you may enjoy understanding this code:

#!/usr/bin/cpr
int main(void) {
CPR_eval("use Inline (C => q{
char* greet() {
return \"Hello world\";
}
})");
printf("%s, I'm running under Perl version %s\n",
CPR_eval("&greet"),
CPR_eval("use Config; $Config{version}"));
return 0;
}

Are you up to date with Perl 6 development? It's going to be great and extremely powerful language. Read Larry Wall's Apocalypses and Damian Conway's Exegeses if you're interested:

• Apocalypse 1: The Ugly, the Bad, and the Good (April 2, 2001)
• Apocalypse 2: Fundamental data types, variables and the context and scoping of the language (May 3, 2001)
• Exegesis 2 (May 15, 2001)
• Apocalypse 3: Operators (October 2, 2001)
• Exegesis 3 (October 3, 2001)
• Apocalypse 4: Syntax (January 18, 2002)

Many problems seem to be so hard to solve that machines wouldn't be able to break through them.

But we just don't know (theorically) if this is true or not :)

There are (afaik) three theories :

• some problems cannot be solved by a machine (and that's fine)
• all problems are solvable by a machine, given a certain amount of time, memory, etc... we don't have for now the right algorithm, that's all (bye bye security ?)
• we just can't make up our mind (no one will [ever ?] know !)

this is about the complexity theory, more links here.

For graphing:

• Grace ( formerly xmgr )

For Numerical Analysis:

• GSL ( Gnu Scientific Library ):

Check out the Scientific Computing FAQ: which I've been having trouble reaching so you might want to try the Google cache of it.

Press releases, FAQ, pictures, and an explanation of the findings may be found here.

-- Tobin