My friend Salvatore and I did a similar site, although we haven't added so many languages and tests, and are more focused on benchmarking. It's available at: scutigena.sf.net
That's a lot of memory for one button. Admittedly, it doesn't grow too fast when I start adding things, but hopefully it's one area where things will improve.
All things considered, I think I like the idea of Mono more than Java, because 1) it's free from the ground up, and if you want it on Linux, you have to use the free version, and 2) the people working on it, like Paolo Molaro, are sharp people I trust.
Yes, it's called "branding". Read up about it in marketing texts.
Sun has been pretty successful so far with the 'pure Java' effort, and I don't think that would stop were it to go open source.
The products of the Apache Software Foundation are covered by a BSD-like license, and yes, some of them have proprietary forks, like WebSphere, but IBM and everyone else keeps coming back to us for the real thing. Same goes for the Java stuff written by our Java-oriented people.
All it takes is them retaining the rights to the Java (TM) name, ala TeX. I.e. you can't call it Java (TM) if it's not compatible. Same thing goes for TCP/IP - that's been open source for a long time, and you don't see a million incompatible versions.
Enforce compatibility through test suites and (open) standards, not by grabbing everyone by the balls via a proprietary platform.
It has been possible for years to quickly and easily develop cross platform GUI's with Tcl and Tk. I just sold an application to a local bookstore that I developed entirely on Linux and then tested a bit on windows before delivering it. Tcl and Tk are quick to develop in, faster than Java for GUI's, and are under a BSD style license.
If Tcl and Tk don't float your boat, check out wxWindows, it looks pretty good as well.
I'm particularly happy that they fixed the PPC threaded core dump bug - if your threaded app dumped core, it oopsed the kernel on PPC, not good! Seems to work fine now:-)
No kidding... that's why it's an example and not a full implementation. You can do all those things in Tcl (or Ruby, Perl, etc...). The idea is that instead of creating some one-off shell, you add a neat feature as an extension to an existing tool.
is all that's needed (of course to do it right you'd need a bit more, but still...).
try {5 times} {
commands... }
Although Tcl is a bit lower level, and would require you to do exec ls, you could of course wrap that too so that all commands in the $script block would just be 'exec'ed by default.
In any case, better to use a flexible tool that can be tweaked to do what you need then write highly specialized tools.
I think Miguel is pretty sharp - with a comment like that, he'll get people talking, if nothing else.
One of the things that strikes me about all this is how, in 2004, some the advantages of Mono are basically what scripting languages have had for ages, and it still isn't there %100.
For instance, "Using Mono vastly reduces the amount of boilerplate code that must be written, along with the opportunity for bugs to creep in.". Well.. I can write even less code in Tcl/Tk (same goes for Python, I'm sure).
Another thing scripting languages have going for them are that they are cross platform. Write once, run anywhere, no bullshit! I recently developed a small application in Tcl/Tk for a client on my PPC Linux machine (I don't run windows at all), did a bit of testing on another friend's windows box, just to be sure, then handed it off to the client. It "just works"!
And yet, with this, we are being told that there are two API's to keep track of. One that might be relatively free of IP problems, and another with Microsoft breathing down its neck. This doesn't bode well for a platform I can write to and then run on different machines.
Of course, C# and Mono are not just a scripting language. They do some neat stuff like JIT compilation, so the code is fast, and can be used for more computationally intensive areas where a scripting language would traditionally be bound to a compiled language via an extesion.
Fast, but it still seems to gobble memory (even if a lot of it is shared):
Which is significantly more than the equivalent Tcl/Tk apps would eat (but around the same, or less than Java?). Seems to do an ok job of sharing memory.
Conclusion: yes, Mono does some things well, and it's certainly got some interesting work that's been put into it, but some of it is ground that others have tread, and done well.
My original post came out kind of garbled:-) But what's wrong with trying to make a buck off of Microsoft? That was their target, not open source projects. As long as we have the current patent system in place, I don't see what's wrong with using it against huge corporations. They wouldn't hesitate to use it against individuals.
The Eolas people never said that they would require that anything other than IE would have to not use their patents, or even have to pay anything to them. They were going after MS and IE.
Not like the courts will do anything. They're sitting on their asses with the existing cases. The Utah one, which was supposed to have an answer "within a week" has been dragging on for something like a month now. The Delaware has seen some action from Redhat and SCO, but nothing from the judge in months. Makes me want to ask the judges what they heck the problem is:-/
The code can be open without the specification and the name being open. You can download Apache and hack it, but you can't call it Apache, for instance. Same goes for TeX.
There are ways to makeTk look more modern, and developing in a scripting language is going to be a heck of a lot faster than waiting around for.NET on Linux to mature. It's also a lot lighter weight than what I have seen so far of mono.
wxWindows is another possibility, although I'm pretty happy with Tcl/Tk myself.
Development has continued throughout the project's life. I think the only thing that was in question was who the code actually belonged to. It's always been GPL'ed.
As to what it's used for, I don't know about commercially, but I've used it for a couple of fun/learning projects: "Scivoli" - a bootable floppy image that loads jpegs from the floppy and displays the to the screen, and "ZOG", which is the ficl forth interpreter layered on top of eCos. Neither one makes much claim to being all that useful, but Scivoli especially shows off how small the OS and display code is (about 130K without much effort at all to reduce it). It would be difficult to squeeze Linux onto a floppy with a bunch of images like I have done. Both are available from http://dedasys.com/freesoftware.
eCos is fun for those learning about OS's because it's well written code, modular, and small enough that it's easier to get a handle on than Linux.
It's designed as a framework that ought to run cross-platform, so you can run it yourself. We haven't added it yet, but I think we really want to divide the tests into two categories. "Get it done" - and each language implements it the best way for that language, and "Basic features comparison" - where each language has to show off features like lists, hash tables, how fast function calls are, and so forth.
It's an ongoing project, so new participants are welcome! I would appreciate it if comments went to the appropriate SF mailing lists instead of here, so that I can better keep track of them.
It would be useful if he could state what his requirements and limits are, in detail, because that's a very necessary part of evaluating what would work.
Anyone know how well it actually works?
on
Home DNA Sequencing
·
· Score: 2, Insightful
I don't mean producing laboratory quality results, just whether it works at all to produce something recognizable? This would be sort of a fun gift for my girlfriend, who is in biotech.
The wallflower is pretty clever, with wireless code and a bunch of other goodies, so it would take quite a bit of work to replicate it.
I created a floppy eCos demo called "Scivoli" that holds the OS + jpegs on a floppy. The OS + app only takes up about 120K so there is a fair amount of space left over for images. More than anything, it's a way to show off eCos... Get it at:
Slashdot Mirror
My friend Salvatore and I did a similar site, although we haven't added so many languages and tests, and are more focused on benchmarking. It's available at: scutigena.sf.net
All things considered, I think I like the idea of Mono more than Java, because 1) it's free from the ground up, and if you want it on Linux, you have to use the free version, and 2) the people working on it, like Paolo Molaro, are sharp people I trust.
Yes, it's called "branding". Read up about it in marketing texts.
Sun has been pretty successful so far with the 'pure Java' effort, and I don't think that would stop were it to go open source.
The products of the Apache Software Foundation are covered by a BSD-like license, and yes, some of them have proprietary forks, like WebSphere, but IBM and everyone else keeps coming back to us for the real thing. Same goes for the Java stuff written by our Java-oriented people.
Oh, come off it.
All it takes is them retaining the rights to the Java (TM) name, ala TeX. I.e. you can't call it Java (TM) if it's not compatible. Same thing goes for TCP/IP - that's been open source for a long time, and you don't see a million incompatible versions.
Enforce compatibility through test suites and (open) standards, not by grabbing everyone by the balls via a proprietary platform.
It has been possible for years to quickly and easily develop cross platform GUI's with Tcl and Tk. I just sold an application to a local bookstore that I developed entirely on Linux and then tested a bit on windows before delivering it. Tcl and Tk are quick to develop in, faster than Java for GUI's, and are under a BSD style license.
If Tcl and Tk don't float your boat, check out wxWindows, it looks pretty good as well.
This has been in the news here in Italy on and off for a couple of months. I'd still want to see it with my own eyes though...
I'm particularly happy that they fixed the PPC threaded core dump bug - if your threaded app dumped core, it oopsed the kernel on PPC, not good! Seems to work fine now:-)
The town of Centralia, Pennsylvania has been on fire (or rather the coal beneath the town has) for more than 40 years. Check it out here:
a li a.htm
http://www.offroaders.com/album/centralia/centr
No kidding... that's why it's an example and not a full implementation. You can do all those things in Tcl (or Ruby, Perl, etc...). The idea is that instead of creating some one-off shell, you add a neat feature as an extension to an existing tool.
... or probably Perl or Python, either.
It doesn't actually seem to grok the commands that are being run, so something like
proc try {times script} {
if { [catch [uplevel $script] err] } { cleanup ; retry }
}
is all that's needed (of course to do it right you'd need a bit more, but still...).
try {5 times} {
commands...
}
Although Tcl is a bit lower level, and would require you to do exec ls, you could of course wrap that too so that all commands in the $script block would just be 'exec'ed by default.
In any case, better to use a flexible tool that can be tweaked to do what you need then write highly specialized tools.
I think Miguel is pretty sharp - with a comment like that, he'll get people talking, if nothing else.
/usr/share/dotnet/gtk-sharp-examples/button.exe
9 048 1820 mono /usr/share/dotnet/gtk-sharp-examples/button.exe
4 1388 11456 mono /usr/share/dotnet/gtk-sharp-examples/scribble.exe
One of the things that strikes me about all this is how, in 2004, some the advantages of Mono are basically what scripting languages have had for ages, and it still isn't there %100.
For instance, "Using Mono vastly reduces the amount of boilerplate code that must be written, along with the opportunity for bugs to creep in.". Well.. I can write even less code in Tcl/Tk (same goes for Python, I'm sure).
Another thing scripting languages have going for them are that they are cross platform. Write once, run anywhere, no bullshit! I recently developed a small application in Tcl/Tk for a client on my PPC Linux machine (I don't run windows at all), did a bit of testing on another friend's windows box, just to be sure, then handed it off to the client. It "just works"!
And yet, with this, we are being told that there are two API's to keep track of. One that might be relatively free of IP problems, and another with Microsoft breathing down its neck. This doesn't bode well for a platform I can write to and then run on different machines.
Of course, C# and Mono are not just a scripting language. They do some neat stuff like JIT compilation, so the code is fast, and can be used for more computationally intensive areas where a scripting language would traditionally be bound to a compiled language via an extesion.
Fast, but it still seems to gobble memory (even if a lot of it is shared):
41336 11872 mono
Which is significantly more than the equivalent Tcl/Tk apps would eat (but around the same, or less than Java?). Seems to do an ok job of sharing memory.
Conclusion: yes, Mono does some things well, and it's certainly got some interesting work that's been put into it, but some of it is ground that others have tread, and done well.
My original post came out kind of garbled:-) But what's wrong with trying to make a buck off of Microsoft? That was their target, not open source projects. As long as we have the current patent system in place, I don't see what's wrong with using it against huge corporations. They wouldn't hesitate to use it against individuals.
The Eolas people never said that they would require that anything other than IE would have to not use their patents, or even have to pay anything to them. They were going after MS and IE.
Not like the courts will do anything. They're sitting on their asses with the existing cases. The Utah one, which was supposed to have an answer "within a week" has been dragging on for something like a month now. The Delaware has seen some action from Redhat and SCO, but nothing from the judge in months. Makes me want to ask the judges what they heck the problem is:-/
The code can be open without the specification and the name being open. You can download Apache and hack it, but you can't call it Apache, for instance. Same goes for TeX.
What portion of their revenue comes from what sources? How much does Java generate, and how? How much does developing it cost them?
It's hard to get an accurate picture without asking some questions like these and getting answers. Otherwise, you can't make an informed judgement.
There are ways to makeTk look more modern, and developing in a scripting language is going to be a heck of a lot faster than waiting around for .NET on Linux to mature. It's also a lot lighter weight than what I have seen so far of mono.
wxWindows is another possibility, although I'm pretty happy with Tcl/Tk myself.
Add Tcl and Tk to the list:-) They have a big test suite which pokes and prods at as many nooks and crannies of the language as possible.
...is people!
First of all, let's say this loud and clear:
eCos is not abandonware!
Development has continued throughout the project's life. I think the only thing that was in question was who the code actually belonged to. It's always been GPL'ed.
As to what it's used for, I don't know about commercially, but I've used it for a couple of fun/learning projects: "Scivoli" - a bootable floppy image that loads jpegs from the floppy and displays the to the screen, and "ZOG", which is the ficl forth interpreter layered on top of eCos. Neither one makes much claim to being all that useful, but Scivoli especially shows off how small the OS and display code is (about 130K without much effort at all to reduce it). It would be difficult to squeeze Linux onto a floppy with a bunch of images like I have done. Both are available from http://dedasys.com/freesoftware.
eCos is fun for those learning about OS's because it's well written code, modular, and small enough that it's easier to get a handle on than Linux.
We weren't quite ready to release it, but we've been working on a language performance comparison test of our own. It is available at:
http://scutigena.sourceforge.net/
It's designed as a framework that ought to run cross-platform, so you can run it yourself. We haven't added it yet, but I think we really want to divide the tests into two categories. "Get it done" - and each language implements it the best way for that language, and "Basic features comparison" - where each language has to show off features like lists, hash tables, how fast function calls are, and so forth.
It's an ongoing project, so new participants are welcome! I would appreciate it if comments went to the appropriate SF mailing lists instead of here, so that I can better keep track of them.
I guess atai must have submitted the same question here as well, but the "original" discussion took place on advogato:
http://www.advogato.org/article/735.html
It would be useful if he could state what his requirements and limits are, in detail, because that's a very necessary part of evaluating what would work.
I don't mean producing laboratory quality results, just whether it works at all to produce something recognizable? This would be sort of a fun gift for my girlfriend, who is in biotech.
The wallflower is pretty clever, with wireless code and a bunch of other goodies, so it would take quite a bit of work to replicate it.
I created a floppy eCos demo called "Scivoli" that holds the OS + jpegs on a floppy. The OS + app only takes up about 120K so there is a fair amount of space left over for images. More than anything, it's a way to show off eCos... Get it at:
http://dedasys.com/freesoftware/
Tinkertoys?
I think it looks surprisingly like Da Vinci's helicopter type drawing:
http://www.emmerling.com/helicopter.jpg
What a brilliant inventor...