I'm not sure there's a difference...it all depends on your definition of "difficult" vs. "expensive". More below...
> I have no clue about how to [motivate and educate the public], but simply forcing the parties to find new ways to get money isn't going to do much.
I totally agree. My preference would be to have more robust competition so that the "market forces" created by the quest for votes trump the market forces created by the quest for dollars.
If we create genuine opportunites for third, fourth, and fifth parties to compete against the big two, they all would need to be more careful about where they accept money from or lose votes to a more cleanly-financed party in the same approximate position in the political spectrum.
In a robust multi-party system, we could probably loosen up on traditional "campaign finance reform" laws, because the incentives built into the system would keep it honest enough.
Note that I'm not arguing for traditional multi-party parliamentary systems, but a new style of multi-party system as described here.
I hope (probably in vain) that we can be smart about how we go about fixing the system. Examples of abuses like this are really repulsive, so don't get me wrong with what I'm about to say. I think all of the hoopla about campaign finance reform misses the point.
I wrote an article for Kuro5hin titled "Campaign Finance Reform: A Red Herring" describing the real problem in detail. The gist is that our current election system is a two-party system, not by design, but by consequence of the current design. Having n choices (where n is hopefully a large number) rather than 2 choices would create a more competitive landscape such that abuse would be made considerably more difficult.
...doesn't venture out much further than an article in Discover Magazine a couple years ago. It pits Brams against Saari, and says "you decide". This one, as opposed to the Discover article, talks about Instant Runoff more, though.
The field is more complicated than that. Saari has made a career out of pushing the Borda count. There are useful applications for it, but I pretty firmly believe public elections are not
It's a pity that Condorcet is ignored here, because he was da man. Condorcet's method kicks butt when compared to Borda and Approval (Approval is simpler to implement, though).
There's a whole bunch of links to articles like this one in the Voting System category in Netscape Open Directory.
There's a lot of different issues in this comment, so I'm going to attempt to extract the discrete issues, and respond to each:
Is the RPSL compatible with the GPL? - In most cases, probably not. We have it on the list of "compatible licenses" to make it clear that we have no beef with other people using the license with their code and combining it with ours. Moreover, there are cases where people place exceptions on top of the GPL that may make it compatible with the RPSL. However, standard GPL software probably can't be combined with RPSL software, due to restrictions in the GPL.
Is Helix license compatible with GStreamer? - Yes, when used correctly. GStreamer is under the LGPL, and the RPSL is compatible with the LGPL when used carefully. There are multiple ways of complying with both licenses; the simplest way is to make sure that there's no mixing of licenses within a particular executable file or dynamic library.
Why did RealNetworks create another license - This is addressed in our posting to the license-discuss alias, as well as my response on Linux Weekly News. In short, we're putting out software that we've invested millions of dollars and seven years developing with dozens of engineers. We've carefully studied all OSI-certified licenses, and understand them completely, but we didn't find one that struck the balance we're trying to achieve.
This question has a couple of dimensions to it: "why should I trust RealNetworks when there are alternatives I trust?", and "how does this relate to GStreamer?". As it turns out, these are very different questions, and I'll answer them both
So, "why should I trust RealNetworks when there are alternatives I trust?" The answer is manyfold. RealNetworks is going to spend a lot of effort building trust in the community. That said, we hope the license is structured such that you don't have to trust us; we intend to have an OSI-certified Open Source license, and go through all of the scrutiny required in getting that mark.
The big benefits for taking a look at RealNetworks is that we are a significant force in the digital media delivery space, and so we offer development resources and investment capability that the open source community can leverage to get a great media player faster than otherwise possible.
Now, "how does this relate to GStreamer?". Well, GStreamer is actually LGPL. As such, I think they are very complementary. GStreamer is working on a different architecture that supports different types of applications than our architecture supports. There's a lot of overlap, but there's also a lot of differing functionality. Over time, with the right effort, I could see there being a nice relationship between the two projects (similar to the relationship between Galeon and Mozilla).
Great question. I can't give you a great answer just yet, but I think we've got a pretty good answer.
We continue to work on the RealOne Player for Linux and for other platforms. However, as you can tell, progress on this hasn't been as fast as we would like.
The great news here, though, is that there is this media engine that we're putting out. We're hoping that GNOME, KDE, Motif/Lesstif and other toolkit-specific GUIs emerge for these (similarly to what has happened with Galeon and Netscape's Gecko engine). We'd love to help facilitate that type of an effort.
So you can handle multiple codecs. So can a dozen other players. Move along people, nothing to see here
It can handle multiple codecs simultaneously, doing real-time mixing of sources and maintaining synchronization defined at the application layer (thus making it capable of supporting SMIL). That narrows the field significantly.
We will be announcing new terms for RealAudio and RealVideo in our October 29 webcast. However, I wouldn't get too excited about some of the possible applications you mention (sorry, I can't be any more specific than that for now). The bottom line is that RealAudio and RealVideo will not be available under the RPSL. I know from talking to Richard Stallman about that that he's not pleased with that. However, he was pleased to hear about our support for Ogg Vorbis (which is progressing nicely).
There are benefits to us not giving away everything. The biggest benefit is that RealNetworks stays motivated to invest heavily in this technology. Because we've got a clear commercial motivation to stay ahead on the technology curve, we're not going to merely lob this over to the open source community and say "here, you deal with it". We absolutely intend to ensure the Helix media engine remains state-of-the-art. (Of course, don't take this to mean that we don't need the community; we do.)
In short, I think there's a lot to be excited about. This is our first big overture to the open source community, but it's not our intention for it to be the last.
The engine we're shipping is the same engine that supports SMIL playback, and does the bulk of the heavy lifting when it comes to handling SMIL. It's not "crippled" in any way.
We're not shipping the actual SMIL file format just yet purely due to time constrants in getting the code released. Taking proprietary code public is not an easy task, and our engineers have been working around the clock to release what we are releasing. We'll hopefully follow up with the actual SMIL code in a later release.
I'm the Helix Community Coordinator (though I'm getting many complaints for my self-chosen wimpy title...suggestions appreciated).
Basically, what's interesting about this is that it's a generalized architecture for any datatype. So, while it's true that there are many MP3 players out there, there's few which are able to handle multiple streams, mixing them with other audio sources, adding in multiple video sources, and hey, throw in some JPEGs, GIFs and Flash while you're at it.
What we're releasing on October 29th won't look very sexy from an end-user perspective. We're basically putting out an engine that'll do all of that stuff with the right plugins. However, it's a down payment on much more. We hope to soon ship support for SMIL, JPEG, GIF, etc.
In the meantime, the technology we're releasing is nothing to sneeze at. I think a lot of the stereotypes about the RealOne Player will be dispelled with the code that we ship. Please take a look, we think you'll like what you see!
Rob
(who's now realizing that he's declared open season on himself for soliciting title suggestions)
Of course, you can argue that giving people more choices results in a better government, but is also results in unfair elections
Arrow's Theorem doesn't draw any such conclusion. Sure, there's no perfect system (by Arrow's set of criteria), but there are systems that are much better than what we've got. Moreover, all that Arrow did was define a set of criteria, and proved that the criteria couldn't be met. He didn't prove that his criteria were correct, because that's a subjective decision that can't be proven.
I'd like to thank Bruce for all of his help in distilling what we are offering. Bruce was in our press conference with his 802.11-equipped laptop helping to put out accurate information from a trusted source. We hope we can still win him over (as well as the rest of the community) when it comes to the value of our offering, which we think is quite substantial.
Additionally, I'd like to thank Eric Raymond and Brian Behlendorf for also being here today, and for their valuable feedback in making sure we're doing the Right Thing(tm). We've also discussed many aspects of this with Emmett Plant and Jack Moffitt of Xiph.org/Vorbis fame as well as Tim O'Reilly and the folks at O'Reilly & Associates, and we're very excited about the opportunities on that horizon. Last but not least, I'd like to thank CollabNet for their incredible help on the launch, and we're looking forward to working with Mark Murphy and the rest of the crew to make Helix into a success.
With regards to the business model, I feel I should respond. This is a very deliberately measured approach to joining the open source community. We have a responsibility to our shareholders to continue to make a profit over the long haul. In the short term, this means withholding some technology to continue forward without drastically altering our current business model.
In the long term, we will be thinking very deeply about how to resolve the business paradox of making money while giving stuff away. It's not new territory for us, but this is certainly a new application of that expertise. Bruce, Eric, Mark Donovan (@RealNetworks) and I had a very interesting conversation at lunch about this, and I'd like to continue this conversation with the them and the rest of the community at OSCON this week.
At any rate, we're very excited about this foray into what's a brave new world for our company. As with any company shifting away from a mosty proprietary software model, I imagine we'll have the occasional faux pas and hiccup. However, I'm incredibly excited about the step we've made, and hopeful that we can have a fruitful partnership with the community (and if someone can come up with a non-nausiating word for "synergistic"...I'll use that too!)
Rob Lanphier Program Manager -- Interoperability RealNetworks
Hmmmm...."Zeinfeld". Pardon me for asking, but whichHTTP author are you? I've met most of you, and like all of you, but quite frankly, at least one of you has a conflict of interest when it comes to opining on BEEP. You're entitled to an opinion, but I think your identity is important data in this case.
As for the IETF being an old boys/girls club...well, yeah. Welcome to politics. I think the IETF has generally been a reasonably equitable old boys club.
But enough about the politics, let's talk about BEEP on its own merits. Maybe the reference implementations are crappy (I can't speak one way or another on that), but the spec looks pretty solid to me. As I said before, it fits the requirements that we had when we were shopping around for a base protocol for RTSP.
At any rate, I encourage people to do some digging themselves on this. I can't say that my experience is overly deep in this area, and I certainly haven't tried to design a protocol on top of BEEP, but based on what I know, BEEP looks like a pretty good idea.
I've also been disappointed with the lack of uptake on BEEP. It's a very cool concept.
BEEP is Blocks Extensible Exchange Protocol (RFC 3080). More details can be found at here.
When we were designing RTSP, we looked for something like this, and at the time, the options weren't very appealing. We ended up using HTTP as a quasi-base protocol. I think it was the best solution at the time, but had BEEP been available, we'd have used it in a heartbeat.
Are you seriously proposing that left-clicking, then right-clicking should have a different behavior than right-clicking alone? Sounds like a usability disaster to me.
Jamie, thanks for pointing out how silly it is for Linux partisans to be big fans of the Darwin server.
Now, regarding video quality. RealVideo 8 is quite good, and in every comparison I've seen, does better than the competition. Of course, I'm a RealNetworks employee, so I'm prone to bias. Still, here's the link to comparitive data on the RealNetworks site, as well as an independent assessment which largely comes to the same conclusions (with some nods to the competition). And, yes, there's a Linux version
As far as server price goes....hey, we've gotta make a living somehow. For the bandwidth necessary to stream to the audiences that you quote, you're going to pay a lot more in bandwidth and infrastructure than in software licenses.
Jeez...don't you know you go to Freshmeat for these things?:)
http://freshmeat.net/projects/realplayer/
Trying to navigate to the right spot from http://www.real.com is trickier, but not impossible. Look for RealPlayer 8, RealPlayer 8 Basic, RealPlayer 8 for UNIX link at bottom of page.
To say that RealServer is expensive is to assume that you need to buy the top-of-the-line product for a small task. The free RealServer Basic serves 25 simultaneous streams, which can pretty quickly fill a T1 depending on the target bitrates.
What Pike offers is great performance and *tight* integration with a high-performance, high-stability web server. I haven't done the benchmarks myself, so I can't offer statistics, but anecdotally, the fact that the web server itself is written mainly in Pike, and the server does pretty well is a good indication. Also anecdotally, I've seen many systems deployed here at RealNetworks that perform very well, and I know that they benchmark well. Maybe I can prod some other more knowledgeable folks here to post.:)
As far as learning a new language goes, it's not that bad, really (it's far from being my "native tongue", so to speak). I find myself reverting to Perl when I want to knock something out quickly, but Pike is not so different as to slow me down all that much.
Our entire website is powered by Roxen (and thus Pike). Having been indoctrinated in Perl and Python, I'll have to admit that when I first became a web developer here and took on learning Yet Another Language I was less than amused.
However, I have to say that I'm impressed with the eye toward performance in Pike (most of the Roxen webserver itself is written in Pike), and the responsiveness of the maintainers when it comes to supporting the product.
ASX is a text format which is a glorified URL list, pointing to mms://... streams (Microsoft's proprietary protocol), and ASF files.
RealPlayer's equivalent to ASX is SMIL, which is a W3C Recommendation, and is usually used to point to RTSP URLs (an IETF Proposed Standard, RFC 2326) and.rm files (or MP3 files, or RealPix, or GIF, or PNG, or JPEG, or whatever)..rm is a proprietary format, but we offer *lots* of standard alternatives.
Hey, they are offering these books to just any old person from any old country! There should be a law against that! STOP THE PROLIFERATION OF WEAPONS OF MATH INSTRUCTION!!!
Slashdot Mirror
Our server will be released early next year. It's in the FAQ.
I'm not sure there's a difference...it all depends on your definition of "difficult" vs. "expensive". More below...
> I have no clue about how to [motivate and educate the public], but simply forcing the parties to find new ways to get money isn't going to do much.
I totally agree. My preference would be to have more robust competition so that the "market forces" created by the quest for votes trump the market forces created by the quest for dollars. If we create genuine opportunites for third, fourth, and fifth parties to compete against the big two, they all would need to be more careful about where they accept money from or lose votes to a more cleanly-financed party in the same approximate position in the political spectrum. In a robust multi-party system, we could probably loosen up on traditional "campaign finance reform" laws, because the incentives built into the system would keep it honest enough. Note that I'm not arguing for traditional multi-party parliamentary systems, but a new style of multi-party system as described here.
I wrote an article for Kuro5hin titled "Campaign Finance Reform: A Red Herring" describing the real problem in detail. The gist is that our current election system is a two-party system, not by design, but by consequence of the current design. Having n choices (where n is hopefully a large number) rather than 2 choices would create a more competitive landscape such that abuse would be made considerably more difficult.
The field is more complicated than that. Saari has made a career out of pushing the Borda count. There are useful applications for it, but I pretty firmly believe public elections are not
It's a pity that Condorcet is ignored here, because he was da man. Condorcet's method kicks butt when compared to Borda and Approval (Approval is simpler to implement, though).
There's a whole bunch of links to articles like this one in the Voting System category in Netscape Open Directory.
Rob
Is the RPSL compatible with the GPL? - In most cases, probably not. We have it on the list of "compatible licenses" to make it clear that we have no beef with other people using the license with their code and combining it with ours. Moreover, there are cases where people place exceptions on top of the GPL that may make it compatible with the RPSL. However, standard GPL software probably can't be combined with RPSL software, due to restrictions in the GPL.
Is Helix license compatible with GStreamer? - Yes, when used correctly. GStreamer is under the LGPL, and the RPSL is compatible with the LGPL when used carefully. There are multiple ways of complying with both licenses; the simplest way is to make sure that there's no mixing of licenses within a particular executable file or dynamic library.
Why did RealNetworks create another license - This is addressed in our posting to the license-discuss alias, as well as my response on Linux Weekly News. In short, we're putting out software that we've invested millions of dollars and seven years developing with dozens of engineers. We've carefully studied all OSI-certified licenses, and understand them completely, but we didn't find one that struck the balance we're trying to achieve.
Rob Lanphier
Helix Community Coordinator
So, "why should I trust RealNetworks when there are alternatives I trust?" The answer is manyfold. RealNetworks is going to spend a lot of effort building trust in the community. That said, we hope the license is structured such that you don't have to trust us; we intend to have an OSI-certified Open Source license, and go through all of the scrutiny required in getting that mark.
The big benefits for taking a look at RealNetworks is that we are a significant force in the digital media delivery space, and so we offer development resources and investment capability that the open source community can leverage to get a great media player faster than otherwise possible.
Now, "how does this relate to GStreamer?". Well, GStreamer is actually LGPL. As such, I think they are very complementary. GStreamer is working on a different architecture that supports different types of applications than our architecture supports. There's a lot of overlap, but there's also a lot of differing functionality. Over time, with the right effort, I could see there being a nice relationship between the two projects (similar to the relationship between Galeon and Mozilla).
Rob Lanphier
Helix Community Coordinator
We continue to work on the RealOne Player for Linux and for other platforms. However, as you can tell, progress on this hasn't been as fast as we would like.
The great news here, though, is that there is this media engine that we're putting out. We're hoping that GNOME, KDE, Motif/Lesstif and other toolkit-specific GUIs emerge for these (similarly to what has happened with Galeon and Netscape's Gecko engine). We'd love to help facilitate that type of an effort.
Rob Lanphier
Helix Community Coordinator
It can handle multiple codecs simultaneously, doing real-time mixing of sources and maintaining synchronization defined at the application layer (thus making it capable of supporting SMIL). That narrows the field significantly.
Rob Lanphier
Helix Community Coordinator
- Be careful what you wish for with MPEG-4, however...
- I share your desire for RTSP world domination
:)
- We will be announcing new terms for RealAudio and RealVideo in our October 29 webcast. However, I wouldn't get too excited about some of the possible applications you mention (sorry, I can't be any more specific than that for now). The bottom line is that RealAudio and RealVideo will not be available under the RPSL. I know from talking to Richard Stallman about that that he's not pleased with that. However, he was pleased to hear about our support for Ogg Vorbis (which is progressing nicely).
- There are benefits to us not giving away everything. The biggest benefit is that RealNetworks stays motivated to invest heavily in this technology. Because we've got a clear commercial motivation to stay ahead on the technology curve, we're not going to merely lob this over to the open source community and say "here, you deal with it". We absolutely intend to ensure the Helix media engine remains state-of-the-art. (Of course, don't take this to mean that we don't need the community; we do.)
In short, I think there's a lot to be excited about. This is our first big overture to the open source community, but it's not our intention for it to be the last.Rob Lanphier
Helix Community Coordinator
We're not shipping the actual SMIL file format just yet purely due to time constrants in getting the code released. Taking proprietary code public is not an easy task, and our engineers have been working around the clock to release what we are releasing. We'll hopefully follow up with the actual SMIL code in a later release.
Rob Lanphier
Helix Community Coordinator
I'm the Helix Community Coordinator (though I'm getting many complaints for my self-chosen wimpy title...suggestions appreciated).
Basically, what's interesting about this is that it's a generalized architecture for any datatype. So, while it's true that there are many MP3 players out there, there's few which are able to handle multiple streams, mixing them with other audio sources, adding in multiple video sources, and hey, throw in some JPEGs, GIFs and Flash while you're at it.
What we're releasing on October 29th won't look very sexy from an end-user perspective. We're basically putting out an engine that'll do all of that stuff with the right plugins. However, it's a down payment on much more. We hope to soon ship support for SMIL, JPEG, GIF, etc.
In the meantime, the technology we're releasing is nothing to sneeze at. I think a lot of the stereotypes about the RealOne Player will be dispelled with the code that we ship. Please take a look, we think you'll like what you see!
Rob
(who's now realizing that he's declared open season on himself for soliciting title suggestions)
Arrow's Theorem doesn't draw any such conclusion. Sure, there's no perfect system (by Arrow's set of criteria), but there are systems that are much better than what we've got. Moreover, all that Arrow did was define a set of criteria, and proved that the criteria couldn't be met. He didn't prove that his criteria were correct, because that's a subjective decision that can't be proven.
For more on this, read this rebuttal of Arrow's theorem-based fatalism.
I'd like to thank Bruce for all of his help in distilling what we are offering. Bruce was in our press conference with his 802.11-equipped laptop helping to put out accurate information from a trusted source. We hope we can still win him over (as well as the rest of the community) when it comes to the value of our offering, which we think is quite substantial.
Additionally, I'd like to thank Eric Raymond and Brian Behlendorf for also being here today, and for their valuable feedback in making sure we're doing the Right Thing(tm). We've also discussed many aspects of this with Emmett Plant and Jack Moffitt of Xiph.org/Vorbis fame as well as Tim O'Reilly and the folks at O'Reilly & Associates, and we're very excited about the opportunities on that horizon. Last but not least, I'd like to thank CollabNet for their incredible help on the launch, and we're looking forward to working with Mark Murphy and the rest of the crew to make Helix into a success.
With regards to the business model, I feel I should respond. This is a very deliberately measured approach to joining the open source community. We have a responsibility to our shareholders to continue to make a profit over the long haul. In the short term, this means withholding some technology to continue forward without drastically altering our current business model.
In the long term, we will be thinking very deeply about how to resolve the business paradox of making money while giving stuff away. It's not new territory for us, but this is certainly a new application of that expertise. Bruce, Eric, Mark Donovan (@RealNetworks) and I had a very interesting conversation at lunch about this, and I'd like to continue this conversation with the them and the rest of the community at OSCON this week.
At any rate, we're very excited about this foray into what's a brave new world for our company. As with any company shifting away from a mosty proprietary software model, I imagine we'll have the occasional faux pas and hiccup. However, I'm incredibly excited about the step we've made, and
hopeful that we can have a fruitful partnership with the community (and if someone can come up with a non-nausiating word for "synergistic"...I'll use that too!)
Rob Lanphier
Program Manager -- Interoperability
RealNetworks
Hmmmm...."Zeinfeld". Pardon me for asking, but which HTTP author are you? I've met most of you, and like all of you, but quite frankly, at least one of you has a conflict of interest when it comes to opining on BEEP. You're entitled to an opinion, but I think your identity is important data in this case.
As for the IETF being an old boys/girls club...well, yeah. Welcome to politics. I think the IETF has generally been a reasonably equitable old boys club.
As for Marshall Rose, he kinda earned his way into the old boys club. He was co-author on many RFCs, including POP3.
But enough about the politics, let's talk about BEEP on its own merits. Maybe the reference implementations are crappy (I can't speak one way or another on that), but the spec looks pretty solid to me. As I said before, it fits the requirements that we had when we were shopping around for a base protocol for RTSP.
At any rate, I encourage people to do some digging themselves on this. I can't say that my experience is overly deep in this area, and I certainly haven't tried to design a protocol on top of BEEP, but based on what I know, BEEP looks like a pretty good idea.
I've also been disappointed with the lack of uptake on BEEP. It's a very cool concept.
BEEP is Blocks Extensible Exchange Protocol (RFC 3080). More details can be found at here.
When we were designing RTSP, we looked for something like this, and at the time, the options weren't very appealing. We ended up using HTTP as a quasi-base protocol. I think it was the best solution at the time, but had BEEP been available, we'd have used it in a heartbeat.
Are you seriously proposing that left-clicking, then right-clicking should have a different behavior than right-clicking alone? Sounds like a usability disaster to me.
Now, regarding video quality. RealVideo 8 is quite good, and in every comparison I've seen, does better than the competition. Of course, I'm a RealNetworks employee, so I'm prone to bias. Still, here's the link to comparitive data on the RealNetworks site, as well as an independent assessment which largely comes to the same conclusions (with some nods to the competition). And, yes, there's a Linux version
As far as server price goes....hey, we've gotta make a living somehow. For the bandwidth necessary to stream to the audiences that you quote, you're going to pay a lot more in bandwidth and infrastructure than in software licenses.
So, can we get a little slack here? :)
Rob
Jeez...don't you know you go to Freshmeat for these things? :)
http://freshmeat.net/projects/realplayer/
Trying to navigate to the right spot from http://www.real.com is trickier, but not impossible. Look for RealPlayer 8, RealPlayer 8 Basic, RealPlayer 8 for UNIX link at bottom of page.
To say that RealServer is expensive is to assume that you need to buy the top-of-the-line product for a small task. The free RealServer Basic serves 25 simultaneous streams, which can pretty quickly fill a T1 depending on the target bitrates.
And which client for Linux or Solaris will you use to hook up to this? (full disclosure: I work for RealNetworks, but I'm not an official spokesman)
Ummm....actually there is. Duverger's law. Read up on it:
http://www.psqonline.org/psabra.html/a& gt;
As far as learning a new language goes, it's not that bad, really (it's far from being my "native tongue", so to speak). I find myself reverting to Perl when I want to knock something out quickly, but Pike is not so different as to slow me down all that much.
However, I have to say that I'm impressed with the eye toward performance in Pike (most of the Roxen webserver itself is written in Pike), and the responsiveness of the maintainers when it comes to supporting the product.
RealPlayer's equivalent to ASX is SMIL, which is a W3C Recommendation, and is usually used to point to RTSP URLs (an IETF Proposed Standard, RFC 2326) and .rm files (or MP3 files, or RealPix, or GIF, or PNG, or JPEG, or whatever). .rm is a proprietary format, but we offer *lots* of standard alternatives.
Hey, they are offering these books to just any old person from any old country! There should be a law against that! STOP THE PROLIFERATION OF WEAPONS OF MATH INSTRUCTION!!!