I love Ruby and Python, but in the general discussion of
dynamic languages, be sure to mention Tcl.
Tcl was heavily supported by Sun, until Sun decided to throw its full weight behind Java.
Between Sun, AOL, and several other companies over the years, the language had enough
development money poured into it to make it easily in the same league as Python, Perl,
Ruby, and even Java. I realize that the topic here is Ruby, but since the general
discussion has drifted to dynamic languages in general, Tcl should also be mentioned.
If anyone is interested in learning more, I think the best place to start is the Tcl'ers
Wiki: http://wiki.tcl.tk
My kids love instant messaging on the computer, and I'd like to teach them Morse/CW. Why not use it for sending messages between kids inside the same school, using tiny, short-range, narrow-bandwith radios? It would certainly make learning to QSO more interesting for the kids.
True, the teachers may not appreciate the kids who secretly send messages back and forth during lectures, but it's not that much different from passing notes. If it really got to be annoying, the radio signals are probably easier to intercept and monitor than sheets of paper anyway.
The walkie-talkies I've seen tend to be 14 channels, but since Morse takes so much less bandwith it seems like a waste to use 1/14th of the available spectrum just for one QSO. Even worse, the only ones I've found are very poor at Morse communication. The buttons don't seem suitable at all for keying, and I'd like to be able to recieve the messages silently somehow instead of that annoying beep.
I tried a few Google searches for some sort of walkie-talkie type of system that was good at sending Morse silently, but to no avail. It seems like it would be a good market -- sort of like sending secret messages, but not really all that secret, since you're broadcasting.
Does anyone know of something suitable for sending silent "instant messaging" in QW, over very short distances (walkie-talkie range or lower)?
William L. Dye ("willdye")
zCW...at... willdye...dot... com
Mod that up! During my recent install of Red Hat 9,
I came to a similar conclusion. Yes, library
dependencies are a problem, but for me the bigger
problem was having everything "just work" once the
installation process was completed. I'm not saying
it's an easy problem to solve, or that other issues
are not worth solving, I'm just adding in my own
feedback. For me, device detection was a bigger
issue than library dependencies.
elocutio writes: Haptics could offer the magical possibility of changing the average gamer from a large cholesterol repository into a lean mass of muscle. Well, maybe not, but it's a neat idea.
I spent several months working on a business plan
for online athletic sports that use networked video games hooked up to exercise equipment. Unfortunately, Nebraska is not exactly the venture capital capital of the world, so it hasn't been easy finding (local) investors. I'd rather not
move to Silicon Valley, so for the moment I've put the plan on hold to pursue other things.
My comment is about the idea that hapics will lead to online athletics. The term "haptics" is generally used to refer to data input, but not necessarily force feedback. Furthermore, there are often substantial differences between force feedback that's designed for accuracy (a big interest to sculptors), and force feedback that's designed for high resistance (so we raise your heart rate). We wouldn't mind accurate feedback in sports, but accuracy has to be traded off with cost, repeatability between machines, the amount of force needed to give the customer a workout, et cetera.
Thus, many of the advances in haptics technology are not of the kind that will get us any closer to true online athletics. To make a business out of games-with-a-workout, it looks like we'll probably have to do more than just wait for the necessary components to be developed in other fields.
--William L. Dye
slash@willdye.com
P.S. I haven't given up on the business idea yet. If anyone is seriously interested in helping, feel free to write.
Zero Knowledge Systems released the source code
to their original Freedom network, with the
exception of the Windows client. I've set up
a Source Forge project to get it up and running
again, at http://tweakdom.sourceforge.net.
Right now the holdup is just figuring out if I
can fire up the network again without getting
into a legal fight. Export laws apparently let
you publish the raw source code, but offering an anonymity service that uses weapons-grade
encryption may be another matter.
I'm trying to make sense of the laws, but at
least for me, "legalese" seems worse than
Perl as a "write-only" language. Since my
objective is just research, I don't mind
complying with the laws. The problem is just
figuring out what the law requires. Uff-da...
Back when the old Freedom network was up and
running, I started a SourceForge project for
making client-side tweaks to their software.
Now that the server code is out, I'll start
another project to try to create an
all-volunteer network that attempts to
replicate at least some of the old functionality.
Those interested should sign on to the
announcement mailing list, at:
OK, so it's crass to reply to your own post with a correction, but mea culpa. My second paragraph should have read:
The basic theories behind nanotech have been subject to scrutiny for decades now, and despite many attempts, nobody has successfully disputed
the core claims. Yes, there are critiques, but look closer and you'll see that the criticisms are either unsupported, or they do not attack the claim about nanotech that is relevant here: the safest bet, by far, is that we will soon have a very large jump in our abilities to send stuff
into space.
Because of Pluto's wide orbital ellipse, it will soon be too far away from the sun and its atmosphere will freeze. So it won't really be the same at all.
Good point. I hadn't thought of that. I'm really glad now that I
specified Pluto as a priority when I filled out the NASA form.:-)
Stop wasting time and money on conventional technology, and go all out
for developing molecular nanotechnology.
The basic theories behind nanotech have been subject to scrutiny for
decades now, and despite many attempts, nobody has successfully disputed
the core claims.
Yes, there are critics, but look closer and you'll see that the claims
are either unsupported, or they do not attack the core claim that is
relevant here: the safest bet, by far, is that we will soon have a very
large jump in our abilities to send stuff into space.
That jump point is close enough now that it doesn't make sense to spend
our resources on conventional technologies.
The planets will still be pretty much the same 5 to 25 years from now,
and whatever we learn from doing things the old-fashioned way isn't
going to be nearly as beneficial as getting the good stuff up and
running sooner.
If you get an unsolicited e-mail in Covalent's name, write directly to company and tell them about it. I know a couple of the guys who work there, and I'm confident that they didn't move halfway across the country just to join the spamming industry. Maybe the list got polluted with your name somehow, or maybe they farmed out the PR stuff to another company. Either way, just give them a chance to fix it.
I used to run a SourceForge project called Tweakdom, which was for tweaks to Freedom's old open-source Linux client. Several months ago, ZKS dropped support of Linux clients, so the project was shut down. We still have the client source code, but in order for the system to work, we needed a network of running servers.
Since ZKS will no longer be in the business, several existing Freedom users have asked ZKS if they would make their old server code available to the open-source community. If that happens, I'll be happy to start up the Tweakdom project again. Here's hopin'...
If you're interested, check the web page for updates, or join the mailing list. Here's the URL's:
While the newer versions of the Freedom client are not scheduled to be ported to Linux, you can still get the source code to the older client and server, at
http://opensource.zeroknowledge.com/.
Zero Knowledge Systems released that code a few months ago, and has not as yet taken down the link.
I started up a
SourceForge
project a while back for tweaks to that source code, called
Tweakdom,
but there didn't seem to be much interest among developers or users, so the project never really got off the ground. So it goes.
I've long wondered if infinity is the culprit behind most instances of unsolvability. At an intuitive level, it makes sense that if I can ask an infinitely-long question, you won't be able to guarantee a finite answer -- if only because I'll never shut up.:-)
Seriously, though, I'd be interested in hearing from Those Who Know The Math Better Than Me: do we still get scads of unsolvabilities when the domain is restricted (as much as possible) to avoid all but the most well-defined instances of infinity?
For the first time this might be truly deentralised so that anyone, anywhere, who was listening to some anonymous and obscure song they liked, would be able to get the information.
You might be interested in the Tropus project, at http://tropus.sourceforge.net. We're still in the vaporware stage, but what you're talking about is one of the things on our wishlist.
Given that laying off Mr. Baker has some potential drawbacks, why not hire him to control the computer-generated R2D2? One of the most important goals of modern computer graphics is to enable actors to do their work easily and intuitively. In most cases, they should not have to know a lot of technical arcana; and in all cases, they should have input devices that are intuitive and efficient.
With some good input devices, and a little training, it seems plausible that Mr. Baker could still be the actor behind R2D2. If anything, it should send a good signal to the acting world that we really mean it when we keep repeating the mantra that "it's the story, not the computers".
For me, at least, it would mean I'd spend less time listening to my peers debate if the new R2D2 is as good as the old one. Anything that helps me get out of analysis mode and back into fantasy mode would be a plus.
There was a recent thread on the Freenet developer's mailing list which may be of interest to you, Cory. Freenet involves transmitting information in a way that may elicit some opposition in certain circumstances. The issue arose that users may want to be able to install, use, then uninstall Freenet in a big fat hurry. Pushing as many Freenet-related files as possible into a single directory would make that process somewhat easier, though considerable doubts were raised that such a scheme was workable or even advisable.
I agree, however, with much of what Cory said about/etc files as "global variables". If only on aesthetic grounds, I like the idea of each program putting most everything into a single directory. A notable exception would be most forms of user data -- I certainly don't advocate putting every file I edit with XEmacs into the same directory as the program files. True, a lot of information about a program does need to be available quickly at some centralized location, such as a list of available programs. That creates a mess of trouble, but not nearly as much as the ad-hoc global-variable approach we have today.
FWIW, the idea of using XML as a config-file format was also briefly discussed. IIRC, the response seemed to be that the developers preferred to stick with a vi-editable text file in the old "keyword=value" format. Oh, well.
Well, if you want to work there, then go hit the careers area of their web site. They're hiring -- if you don't mind moving to Chicago.
--willdye
P. S. It just occurred to me that there's something really appropriate about using Linux boxes to do an animated series about space-faring penguins . I guess it's only a matter of time before Tux the penguin makes a cameo appearance. Maybe even a Tux-like regular character? Hmm. They should at least give him the appropriate accent. Remember, Big Idea, it's "Leenus", not "Liinus". Think pickled herring, not Peanuts.:-)
FWIW, here's a copy of the e-mail that I sent.
on
Hemos Gets Hitched
·
· Score: 1
Haw! A request to spam someone's mailbox, posted on Slashdot, on the front page, by the Burrito Brigadier himself! All that's missing is a cc to the e-mail spam lists asking everyone to forward it to all their friends because some poor person dying of cancer gets five cents from Bill Gates for every message they receive.
(Pauses, grinning broadly, to soak in the irony)
OK, now to the important stuff. Congratulations to you & Miss Lane on your wedding! May God bless you both with many, many happy years together.
--William Dye (no one you've met, just another Slashdot & Nanodot reader) willdye@dsndata.com
A friend of mine, Jon Travis, hacked out some cool software called Camserv that does streaming video on Linux, FreeBSD, NetBSD, and BSDi systems. Check the Camserv home page for details.
Camserv addresses collecting the images, but not storing them. I wrote a quick hack script that took one image every second and stored it on disk, but that translates into a coupla hundred megs of jpeg's per day, depending on resolution and such. A good encoding system should be able to substantially cut down the bit bloat, especially if most of the images are static most of the time. Scroll down the Slashdot topics a bit and you should see some discussions of (*ahem*) "MP4" and the like.
For legal purposes, though, you may want to keep around the original jpeg images for a few days. Don't let the opposing lawyer bog things down with accusations that your compression software has somehow made the thief in the video look exactly like their client. That's easy to disprove, but most everything is expensive in a courtroom (even in Canada).
--William L. Dye, A.K.A. "willdye", A.K.A. "Boba Fudd", A.K.A. "Darth Fudd", A.K.A. Lots of other stuff:-)
Slashdot Mirror
I love Ruby and Python, but in the general discussion of dynamic languages, be sure to mention Tcl. Tcl was heavily supported by Sun, until Sun decided to throw its full weight behind Java. Between Sun, AOL, and several other companies over the years, the language had enough development money poured into it to make it easily in the same league as Python, Perl, Ruby, and even Java. I realize that the topic here is Ruby, but since the general discussion has drifted to dynamic languages in general, Tcl should also be mentioned. If anyone is interested in learning more, I think the best place to start is the Tcl'ers Wiki: http://wiki.tcl.tk
True, the teachers may not appreciate the kids who secretly send messages back and forth during lectures, but it's not that much different from passing notes. If it really got to be annoying, the radio signals are probably easier to intercept and monitor than sheets of paper anyway.
The walkie-talkies I've seen tend to be 14 channels, but since Morse takes so much less bandwith it seems like a waste to use 1/14th of the available spectrum just for one QSO. Even worse, the only ones I've found are very poor at Morse communication. The buttons don't seem suitable at all for keying, and I'd like to be able to recieve the messages silently somehow instead of that annoying beep.
I tried a few Google searches for some sort of walkie-talkie type of system that was good at sending Morse silently, but to no avail. It seems like it would be a good market -- sort of like sending secret messages, but not really all that secret, since you're broadcasting. Does anyone know of something suitable for sending silent "instant messaging" in QW, over very short distances (walkie-talkie range or lower)?
William L. Dye ("willdye") ...at... willdye ...dot... com
zCW
Mod that up! During my recent install of Red Hat 9, I came to a similar conclusion. Yes, library dependencies are a problem, but for me the bigger problem was having everything "just work" once the installation process was completed. I'm not saying it's an easy problem to solve, or that other issues are not worth solving, I'm just adding in my own feedback. For me, device detection was a bigger issue than library dependencies.
I spent several months working on a business plan for online athletic sports that use networked video games hooked up to exercise equipment. Unfortunately, Nebraska is not exactly the venture capital capital of the world, so it hasn't been easy finding (local) investors. I'd rather not move to Silicon Valley, so for the moment I've put the plan on hold to pursue other things.
My comment is about the idea that hapics will lead to online athletics. The term "haptics" is generally used to refer to data input, but not necessarily force feedback. Furthermore, there are often substantial differences between force feedback that's designed for accuracy (a big interest to sculptors), and force feedback that's designed for high resistance (so we raise your heart rate). We wouldn't mind accurate feedback in sports, but accuracy has to be traded off with cost, repeatability between machines, the amount of force needed to give the customer a workout, et cetera.
Thus, many of the advances in haptics technology are not of the kind that will get us any closer to true online athletics. To make a business out of games-with-a-workout, it looks like we'll probably have to do more than just wait for the necessary components to be developed in other fields.
--William L. Dye
slash@willdye.com
P.S. I haven't given up on the business idea yet. If anyone is seriously interested in helping, feel free to write.
Right now the holdup is just figuring out if I can fire up the network again without getting into a legal fight. Export laws apparently let you publish the raw source code, but offering an anonymity service that uses weapons-grade encryption may be another matter.
I'm trying to make sense of the laws, but at least for me, "legalese" seems worse than Perl as a "write-only" language. Since my objective is just research, I don't mind complying with the laws. The problem is just figuring out what the law requires. Uff-da...
--Will
Those interested should sign on to the announcement mailing list, at:
http://tweakdom.sourceforge.net
--Will
The basic theories behind nanotech have been subject to scrutiny for decades now, and despite many attempts, nobody has successfully disputed the core claims. Yes, there are critiques, but look closer and you'll see that the criticisms are either unsupported, or they do not attack the claim about nanotech that is relevant here: the safest bet, by far, is that we will soon have a very large jump in our abilities to send stuff into space.
--Typo Willdye
Because of Pluto's wide orbital ellipse, it will soon be too far away from the sun and its atmosphere will freeze. So it won't really be the same at all.
Good point. I hadn't thought of that. I'm really glad now that I specified Pluto as a priority when I filled out the NASA form. :-)
--Will
The basic theories behind nanotech have been subject to scrutiny for decades now, and despite many attempts, nobody has successfully disputed the core claims. Yes, there are critics, but look closer and you'll see that the claims are either unsupported, or they do not attack the core claim that is relevant here: the safest bet, by far, is that we will soon have a very large jump in our abilities to send stuff into space.
That jump point is close enough now that it doesn't make sense to spend our resources on conventional technologies. The planets will still be pretty much the same 5 to 25 years from now, and whatever we learn from doing things the old-fashioned way isn't going to be nearly as beneficial as getting the good stuff up and running sooner.
Put the money into making nanotech work. Now.
--willdye
--Will
Since ZKS will no longer be in the business, several existing Freedom users have asked ZKS if they would make their old server code available to the open-source community. If that happens, I'll be happy to start up the Tweakdom project again. Here's hopin'...
If you're interested, check the web page for updates, or join the mailing list. Here's the URL's:
The Tweakdom web page: http://tweakdom.sourceforge.net
The Tweakdom mailing list: http://sourceforge.net/mail/?group_id=23929
--willdye
--William L. Dye
willdye at willdye dot com
Seriously, though, I'd be interested in hearing from Those Who Know The Math Better Than Me: do we still get scads of unsolvabilities when the domain is restricted (as much as possible) to avoid all but the most well-defined instances of infinity?
--Will
You might be interested in the Tropus project, at http://tropus.sourceforge.net. We're still in the vaporware stage, but what you're talking about is one of the things on our wishlist.
--William Dye
With some good input devices, and a little training, it seems plausible that Mr. Baker could still be the actor behind R2D2. If anything, it should send a good signal to the acting world that we really mean it when we keep repeating the mantra that "it's the story, not the computers".
For me, at least, it would mean I'd spend less time listening to my peers debate if the new R2D2 is as good as the old one. Anything that helps me get out of analysis mode and back into fantasy mode would be a plus.
--Will
willdye@willdye.com
I agree, however, with much of what Cory said about /etc files as "global variables". If only on aesthetic grounds, I like the idea of each program putting most everything into a single directory. A notable exception would be most forms of user data -- I certainly don't advocate putting every file I edit with XEmacs into the same directory as the program files. True, a lot of information about a program does need to be available quickly at some centralized location, such as a list of available programs. That creates a mess of trouble, but not nearly as much as the ad-hoc global-variable approach we have today.
FWIW, the idea of using XML as a config-file format was also briefly discussed. IIRC, the response seemed to be that the developers preferred to stick with a vi-editable text file in the old "keyword=value" format. Oh, well.
--Will
Well, if you want to work there, then go hit the careers area of their web site. They're hiring -- if you don't mind moving to Chicago.
--willdye
P. S. It just occurred to me that there's something really appropriate about using Linux boxes to do an animated series about space-faring penguins . I guess it's only a matter of time before Tux the penguin makes a cameo appearance. Maybe even a Tux-like regular character? Hmm. They should at least give him the appropriate accent. Remember, Big Idea, it's "Leenus", not "Liinus". Think pickled herring, not Peanuts. :-)
(Pauses, grinning broadly, to soak in the irony)
OK, now to the important stuff. Congratulations to you & Miss Lane on your wedding! May God bless you both with many, many happy years together.
--William Dye (no one you've met, just another Slashdot & Nanodot reader)
willdye@dsndata.com
Camserv addresses collecting the images, but not storing them. I wrote a quick hack script that took one image every second and stored it on disk, but that translates into a coupla hundred megs of jpeg's per day, depending on resolution and such. A good encoding system should be able to substantially cut down the bit bloat, especially if most of the images are static most of the time. Scroll down the Slashdot topics a bit and you should see some discussions of (*ahem*) "MP4" and the like.
For legal purposes, though, you may want to keep around the original jpeg images for a few days. Don't let the opposing lawyer bog things down with accusations that your compression software has somehow made the thief in the video look exactly like their client. That's easy to disprove, but most everything is expensive in a courtroom (even in Canada).
--William L. Dye, A.K.A. "willdye", A.K.A. "Boba Fudd", A.K.A. "Darth Fudd", A.K.A. Lots of other stuff :-)
willdye@sds2.com
(Not speaking for my employers)