Although the article focused on clients for AIM, it would be wise to mention other, and IMHO superior systems such as Jabber and others.
Jabber has several strengths over other Open Source IM projects. I'll name a few:
<ol>
<li> Based on open standards all around, no proprietary secret parts. Jabber is part of the IETF effort to develop open IM protocol standards.
<li> Uses XML for protocol and messages.. This turns out to be a powerful (hm.. I guess some people will disagree with this) application level protocol language.
<li> The scope of this open architecture is much wider than IM between people. Communication with appliances and remote control of everything from dishwashers, ovens, DVD/CD players, RealTime MPEG-2 video-recorders, and so on.
</ol>
Before we know it Jabber, or similar XML-based IM systems, might be the emerging standard of "home network appliance inter-communication". (maybe I should trademark that sentence:-)
If you compare the potential functionality of Jabber with other emerging standards like RTSP (RealTime Streaming Protocol) there is a lot of similarity, and XML-based IM-protocols might well end up being the leading contender for home-network Human<->appliance appliance<->appliance communication.
I'm probably stating the obvious to many slashdot readers, but in my NSHO it's one of the most exciting developments within the OpenSource community at the moment.
Any reader who's interested in learning more about this should check out:
<a href="http://www.jabber.org/">www.jabber.org</a>
and also skim through <a href="ftp://ftp.isi.edu/in-notes/rfc2326.txt">T he RFC for RTSP</a> for one of many areas where XML-based IM-systems might turn out to be the best and most flexible technology.
Reading the other comments I discovered there were several things not mentioned yet.
An important part of my work is being responsible for all streaming done by the Norwegian Broadcasting Corporation (NRK - http://www.nrk.no). We stream all NRK radio-channels in Real, MP3, and with Multicast over the Mbone in both PCM mu-law, and MP3 format.
This is a short runthrough of our most successful setup, with comments regarding your question:
1) Yes Linux is the best choice AFAIK for the OS. An alternative is any of the other FREE Un*x'es. - Linux is stable, - Linux is free. We've run Real and MP3 servers on WinNT, IRIX, and Linux. What would be a moderate (PII-300) Linux server outperform any of them.
2) Your best choice for MP3-streaming software would clearly be Icecast (www.icecast.org). It is free, stable, and easy to install. We use Icecast for all our MP3-streaming. We are in the process of replacing all our Real Servers with Icecast.
3) As others have said: Your biggest enemy will be bandwidth. It is easy to setup Icecast to relay your mp3-stream to another server with more bandwidth. As a sidenote: Unicast streaming is hell on bandwidth. Multicasting is a much better choice. Unfortunately Multicasting is still a long way from being implemented in most parts of the commercial Internet.
4) Live MP3 encoding: Use Lame (http://www.sulaco.org/mp3/download/download.html) , or GoGo (based on Lame). We use Lame for all our MP3-encoding.
5) Also you do not need to use Shout or Liveice to get the stream to your server. Remember that Icecast (and shoutcast) is nothing but a scaled down, and optimized(we wish:) http-server. Also: You do not need to store all that mp3 on your harddisk. We use FIFO-pipes and a tool called nc for all our streaming.
Here's and example: First: Use 'mkfifo' to make FIFO-pipes somewhere on your filesystem. (Here we use/tmp/)
mkfifo -m 644/tmp/my-live-stream
then use Sox to grab the audio from your soundcard and pipe it to Lame (which reads from STDIN and writes to your FIFO-pipe):
Create a file with settings for the Icecast-server. This is normally one of the things Shout and Liveice does, but we are connecting to the Icecast server directly, so we do it by hand. Here is the settings file we use for streaming radio: Let's say we store it in:/tmp/settings.txt --- SOURCE [SERVER SOURCE PASSWORD]/[mountpoint on server] x-audiocast-bitrate: [encoding bitrate] x-audiocast-name: [The name of the broadcast] x-audiocast-genre: [the genre of the broadcast] x-audiocast-url: [broadcast URL] x-audiocast-mount:/[mountpoint on server] x-audiocast-description: Icy protocol in use x-audiocast-public: 1 ---
It might be a good idea to put the above commands in a script. If you start writing to a FIFO-buffer and you take to long starting to read from it the buffer will time out, and the connection to the icecast-server will fail.
The main problem I see, with portraying computers/hackers/crackers in movies, is that most screenwriters, directors and producers don't know enough about computers to make it exciting or accurate enough on screen.
Even if some of us at/. sat down and wrote a real cool "Linux/hacker outfit takes on the evil NSA/corrupt pentagon" script, AND got a really great director, chances are the producers would still sit there and go: "uh.. I don't get that? Why don't you guys make the screens more colorful, and.. uh.. the text has got to be bigger and readable.. and uh.. you need one of those "you've got mail" graphics.
I really believe it is possible to make a cool Linux/hacker/Internet movie which is accurate and cool at the same time. But you need people with real hacking/computing knowledge to write the script, you need a director with real integrity, and I'm sure you'll need final cut over the finished movie.
Multicast will not solve the Video on Demand problem. Your description of the bandwidth problem and your definition of VoD is very good. I believe real Video on Demand most likely will be made possible by using a caching system somewhat similar to todays web-proxies and caches like squid,etc. I know several people within IETF and TERENA are working on this already. But as you, I belive the future will bring both multicasted "broadcasts" and pure Video on Demand. I think of a system similar to todays Icecast with multicast, capable of streaming video. And a network of local media-caches keeping unnecessary traffic off the common Internet backbone.
I work on a similar video-streaming project at Østfold College in Norway, and it is my belief that On Demand Video will be available over the Internet sooner than we might think.
The project I work on are doing live video-broadcasts of two TV-channels over IPv4, using multicast (read MBONE), with bandwidth consumption up to 2Mbit/s per stream. We are using standard PentiumII workstations running Linux-2.2.12 and bttv grabbercards throughout the whole project. As long as you've got the bandwidth it works perfectly.:) The boxes never crashes either.
Today NASA is doing multicast-transmissions of about 20 or so educational programs. They are using MPEG-1 video, MP3 audio, 1.5 Mbit/s streams. I receive those streams perfectly at my office in Norway (other side of the world, plain old IPv4 internet, no fancy stuff, just _bandwidth_ and multicasting).
DVD quality MPEG-2 streaming uses bandwidth up to 6-8 Mbit/s. This is the same as the european Digital TV standard. The next goal of my project is to start streaming live MPEG-2 encoded video over the Internet. We will start doing this before christmas.
Alot of ISP's (at least in Norway) are starting to build Wireless (WaveLan) Wide Area Networks with bandwidth ranging from 2Mbit to 11Mbit per second.
The theoretical bandwidth of one fiber-optic strand is reaching the Terrabit level and rising. As the telcos (and others) are starting to give fiber to the end user, the bandwith of the internet will reach Petabit level.
Oh and by the way: MBONE is not dead. IETF declared Multicasting to be a part of any full IP implementation, so MBONE is not something other than IP, MBONE is a part of IP, it's just that alot of ISP's has not understood this yet. Multicasting is also an integrated part of IPv6, and IPv6 is dependent of Multicasting to a much larger degree than IPv4.
I believe Internet Video On Demand will develop very similar to mp3. Here is a short scenario of how I think this will develop the next two or three years. - First computers will become fast enough to encode and decode DVD quality MPEG-2 in realtime. (1-2 years) - Then the bandwidth will be available to stream and download video, over the network. (2-5 years) - After that some people will find a way to rip the decrypted video of DVD-disks. (now-1 year) - Then people will start to encode favorite movies and TV-shows themselves and you and I can download all episodes of Seinfeld and Babylon 5 of the net, and then the television and movie people will have a very hard time sleeping at night. (now: mpeg1, 2 years: mpeg-2)
Slashdot Mirror
Although the article focused on clients for AIM, it would be wise to mention other, and IMHO superior systems such as Jabber and others.
:-)
;/a>
Jabber has several strengths over other Open Source IM projects. I'll name a few:
<ol>
<li> Based on open standards all around, no proprietary secret parts. Jabber is part of the IETF effort to develop open IM protocol standards.
<li> Uses XML for protocol and messages.. This turns out to be a powerful (hm.. I guess some people will disagree with this) application level protocol language.
<li> The scope of this open architecture is much wider than IM between people. Communication with appliances and remote control of everything from dishwashers, ovens, DVD/CD players, RealTime MPEG-2 video-recorders, and so on.
</ol>
Before we know it Jabber, or similar XML-based IM systems, might be the emerging standard of "home network appliance inter-communication". (maybe I should trademark that sentence
If you compare the potential functionality of Jabber with other emerging standards like RTSP (RealTime Streaming Protocol) there is a lot of similarity, and XML-based IM-protocols might well end up being the leading contender for home-network Human<->appliance appliance<->appliance communication.
I'm probably stating the obvious to many slashdot readers, but in my NSHO it's one of the most exciting developments within the OpenSource community at the moment.
Any reader who's interested in learning more about this should check out:
<a href="http://www.jabber.org/">www.jabber.org<
and also skim through <a href="ftp://ftp.isi.edu/in-notes/rfc2326.txt">T he RFC for RTSP</a> for one of many areas where XML-based IM-systems might turn out to be the best and most flexible technology.
Reading the other comments I discovered there were several things not mentioned yet.
) , or GoGo (based on Lame). We use Lame for all our MP3-encoding.
:) http-server.
/tmp/)
/tmp/my-live-stream
/dev/dsp -t wav - | lame -b - - > /tmp/my-live-stream
/tmp/settings.txt /[mountpoint on server] /[mountpoint on server]
/cat/settings.txt /tmp/my-live-stream | nc -w 30 [my icecast server] [port] &
An important part of my work is being responsible for all streaming done by the Norwegian Broadcasting Corporation (NRK - http://www.nrk.no). We stream all NRK radio-channels in Real, MP3, and with Multicast over the Mbone in both PCM mu-law, and MP3 format.
This is a short runthrough of our most successful setup, with comments regarding your question:
1) Yes Linux is the best choice AFAIK for the OS. An alternative is any of the other FREE Un*x'es.
- Linux is stable, - Linux is free. We've run Real and MP3 servers on WinNT, IRIX, and Linux. What would be a moderate (PII-300) Linux server outperform any of them.
2) Your best choice for MP3-streaming software would clearly be Icecast (www.icecast.org). It is free, stable, and easy to install. We use Icecast for all our MP3-streaming. We are in the process of replacing all our Real Servers with Icecast.
3) As others have said: Your biggest enemy will be bandwidth. It is easy to setup Icecast to relay your mp3-stream to another server with more bandwidth. As a sidenote: Unicast streaming is hell on bandwidth. Multicasting is a much better choice. Unfortunately Multicasting is still a long way from being implemented in most parts of the commercial Internet.
4) Live MP3 encoding: Use Lame (http://www.sulaco.org/mp3/download/download.html
5) Also you do not need to use Shout or Liveice to get the stream to your server. Remember that Icecast (and shoutcast) is nothing but a scaled down, and optimized(we wish
Also: You do not need to store all that mp3 on your harddisk. We use FIFO-pipes and a tool called nc for all our streaming.
Here's and example:
First: Use 'mkfifo' to make FIFO-pipes somewhere on your filesystem. (Here we use
mkfifo -m 644
then use Sox to grab the audio from your soundcard and pipe it to Lame (which reads from STDIN and writes to your FIFO-pipe):
sox -t ossdsp -c 2 -r 44100 -w -s
Create a file with settings for the Icecast-server. This is normally one of the things Shout and Liveice does, but we are connecting to the Icecast server directly, so we do it by hand. Here is the settings file we use for streaming radio: Let's say we store it in:
---
SOURCE [SERVER SOURCE PASSWORD]
x-audiocast-bitrate: [encoding bitrate]
x-audiocast-name: [The name of the broadcast]
x-audiocast-genre: [the genre of the broadcast]
x-audiocast-url: [broadcast URL]
x-audiocast-mount:
x-audiocast-description: Icy protocol in use
x-audiocast-public: 1
---
Then run the command:
cat
It might be a good idea to put the above commands in a script. If you start writing to a FIFO-buffer and you take to long starting to read from it the buffer will time out, and the connection to the icecast-server will fail.
I hope this is helpful.
The main problem I see, with portraying computers/hackers/crackers in movies, is that most screenwriters, directors and producers don't know enough about computers to make it exciting or accurate enough on screen.
Even if some of us at
I really believe it is possible to make a cool Linux/hacker/Internet movie which is accurate and cool at the same time. But you need people with real hacking/computing knowledge to write the script, you need a director with real integrity, and I'm sure you'll need final cut over the finished movie.
- Thomas
Multicast will not solve the Video on Demand problem. Your description of the bandwidth problem and your definition of VoD is very good. I believe real Video on Demand most likely will be made possible by using a caching system somewhat similar to todays web-proxies and caches like squid,etc. I know several people within IETF and TERENA are working on this already. But as you, I belive the future will bring both multicasted "broadcasts" and pure Video on Demand. I think of a system similar to todays Icecast with multicast, capable of streaming video. And a network of local media-caches keeping unnecessary traffic off the common Internet backbone.
I work on a similar video-streaming project at Østfold College in Norway, and it is my belief that On Demand Video will be available over the Internet sooner than we might think.
:) The boxes never crashes either.
:)
The project I work on are doing live video-broadcasts of two TV-channels over IPv4, using multicast (read MBONE), with bandwidth consumption up to 2Mbit/s per stream. We are using standard PentiumII workstations running Linux-2.2.12 and bttv grabbercards throughout the whole project. As long as you've got the bandwidth it works perfectly.
Today NASA is doing multicast-transmissions of about 20 or so educational programs. They are using MPEG-1 video, MP3 audio, 1.5 Mbit/s streams. I receive those streams perfectly at my office in Norway (other side of the world, plain old IPv4 internet, no fancy stuff, just _bandwidth_ and multicasting).
DVD quality MPEG-2 streaming uses bandwidth up to 6-8 Mbit/s. This is the same as the european Digital TV standard. The next goal of my project is to start streaming live MPEG-2 encoded video over the Internet. We will start doing this before christmas.
Alot of ISP's (at least in Norway) are starting to build Wireless (WaveLan) Wide Area Networks with bandwidth ranging from 2Mbit to 11Mbit per second.
The theoretical bandwidth of one fiber-optic strand is reaching the Terrabit level and rising. As the telcos (and others) are starting to give fiber to the end user, the bandwith of the internet will reach Petabit level.
Oh and by the way: MBONE is not dead. IETF declared Multicasting to be a part of any full IP implementation, so MBONE is not something other than IP, MBONE is a part of IP, it's just that alot of ISP's has not understood this yet. Multicasting is also an integrated part of IPv6, and IPv6 is dependent of Multicasting to a much larger degree than IPv4.
I believe Internet Video On Demand will develop very similar to mp3. Here is a short scenario of how I think this will develop the next two or three years.
- First computers will become fast enough to encode and decode DVD quality MPEG-2 in realtime. (1-2 years)
- Then the bandwidth will be available to stream and download video, over the network. (2-5 years)
- After that some people will find a way to rip the decrypted video of DVD-disks. (now-1 year)
- Then people will start to encode favorite movies and TV-shows themselves and you and I can download all episodes of Seinfeld and Babylon 5 of the net, and then the television and movie people will have a very hard time sleeping at night. (now: mpeg1, 2 years: mpeg-2)
ust my 2 cents of humble opinion.