I was of the understanding that the human genome project was funded and overseen by the United States Department of Energy? Doesn't this more or less nullify patenting of that information?
Well, not quite. It is publicly funded, I believe most of the US support is from NIH. The Human Genome project is an international effort.
The conflict here (did you read the article?) is between the Genome project and a private company, Celera, which is racing to sequence and patent as much of the human genome as possible before the Human Genome project does. The two have been in talks to assimilate the data into a single database, but they seem to be hung up on intellectual property issues.
I think you missed my point here. I don't want to support these OSes. I just want the standards that people are using on the internet to be open. Then if someone cares, they can port something to whatever operating system they happen to like using.
Personally, I'm sad to see support for Unix systems (other than Linux x86) declining. RealPlayer is still at version 5 for most Unix platforms. I don't really care on a personal level whether BeOS (for example) has the latest and greatest support for audio streaming. But I don't think that a smaller niche OS should be prevented from using a particular internet standard just because it isn't in the interest of a particular company to develop a client for that platform. That's the major problem with proprietary formats, and I don't think Linux users should be placated by the extension of this closed format to the x86 platform. Everyone else still gets left behind.
And not just Linux non-x86 platforms are left out: so are other Unices, not to mention other OSes like BeOS and OS/2.
The Linux community is often guilty of the same assumptions that they so deplore in Windows users: that everyone uses the same as they do. Just as "computer" means a Windows-based PC to most people, "Linux" means Linux-x86 to most users. And they can be somewhat blind to those other operating systems with smaller user bases.
I don't think the RedHat-Real partnership is necessarily a bad thing. It's an OK thing. But it may take our eyes away from some more important goals: real freedom of choice and transparent interoperability. For this, we need real open standards (an open Real standard would be nice). Streaming media at the moment is essentially a contest between two closed, proprietary formats, and not only will neither company do the work to port their clients (not to mention servers) to OSes with a smaller user base (Redhat Linux x86 apparently has made the threshold now), but because the formats themselves are closed, no one else could do it if they wanted to.
Open standards are essential. Open source implementations can come next.
A shuttle launch costs more like $500 million (depending on how you do the accounting).
The outside limit of the shuttle's maximum landing payload is about 50,000 pounds. With gold at about $300 per troy ounce, that's about $220 million in bullion you could bring back, if it was already hanging around in low earth orbit.
You still lose plenty. Or rather, the taxpayers do.
PS Sorry about the lame units, that's how NASA gives the numbers. And gold is always troy ounces.
I agree completely, neither vi nor emacs has a very intuitive interface. But I would argue that both have very efficient interfaces for experienced users. Yes, the learning curve is steeper. But once you have made it a good way up the curve, you can get things done much, much faster than you could in any more "intuitive" interface.
I have nothing against easy-to-learn applications, they should exist for people who prefer them, but "expert" level interfaces like vi and emacs can't be beat for getting complex tasks done very quickly.
When is the last time a new major version release ever led to "a more stable and faster Netscape"? It just gets slower and more bloated with every upgrade. I kept using 3.0 for as long as possible before upgrading to the 4.x series. But nowadays, too many things require version 4 browsers.
Perhaps Mozilla is the only hope for a non-Microsoft broswer, I don't know. But I don't plan to upgrade until there is a browser actually working that is in fact both faster and more stable. I have little expectation that this will be Netscape Navigator 5.0.
The soundtrack to the novel was indeed Nick Cave, it seems. I heard William Gibson on the BBC Radio 4 program "Desert Island Discs" this morning, in which he chose the 8 records he would get to have with him if stranded on a desert island. One was Nick Cave's "Are You the One I've Been Looking For", which was also his top choice if he had to narrow it down to one disc only.
Another of the songs was an early demo of "All Tomorrow's Parties" by Velvet Underground. He also picked another John Cale song, performed by someone else. The remaining 5 tracks were by Doc Boggs, Steely Dan, Bruce Springsteen, Tom Waits and Taj Mahal. It was a great program, and I even looked around to see if it was archived on the web but had no luck. Anyone know if the Beeb has RealAudio archives of programs like this somewhere?
First of all, it's odd for me, a native English speaker who happens to be living in France, to be automatically redirected to a French language page. But it starts getting to be annoying when I start out on the English page, search for Excite and end up on their Excite redirection page, which is back in the Lycos.com domain, do a search with the link on that page, and end up on the French language home page anyway!
Granted, it's hard for an English speaker to complain about the language content of the web (which must still be 90% English), but sheesh! If I start out specifying the language, shouldn't I at least stay in that language? Especially if it happens to be the original language of the site.
Massachusetts has called itself a Commonwealth at least since 1780, back when the "Commonwealth" you refer to was still the British Empire, and would be for some time to come.
I completely fail to see how filtering of one's own choosing is bad. OK, I agree that it can possibly border on censorship if it's not your own doing, but then again, it can just be good editing. If I want to read content that's been checked and edited and filtered, I'll read the NY Times or equivalent. If I don't, I'll read Usenet. Guess which one I read more often. Slashdot is great because we can choose exactly how we want to do the filtering. So some people don't want to read Jon Katz - why is it worse to have him automatically not listed than just to skim over and not click the titles? It's still their choice.
One thing the web shows again and again is the importance of editors. I think they will become more, not less, important in the future. We can't read everything, and it's good to have ways to choose what's important. Sometimes it will be a real person (or people), sometimes it will be a team of moderators and/or user preferences, like Slashdot.
More choice is good. So are more ways to find the things we actually want to take the time to read.
Naturally if the files are encoded at the same bitrate, (e.g. 128kbps) they will have (approximately) the same size. What they are arguing is that the M$ format sounds slightly better at about half the bits/second.
I don't know whether it's true, I haven't heard it, but that's what they're claiming. So encode an MP3 at 128kbps and a M$ format file at 64kbps and see what you get.
One of the results from all these searches that I would think would be most interesting is the number of stars that apparently _do not_ have planets (within the limits of resolution, of course) relative to the number that do. I've never seen that talked about in any of the popular press reports or even the general articles in Nature or Science. Perhaps the astronomy literature deals with the question.
By now, with so many of these systems known, shouldn't we be able to start taking stabs at the statistics of solar system formation, at least for Jupiter-sized planets and up?
Is there a good solution for offline RealAudio? What I'd really like to do is slurp down files listed in a.ram (or.rmm) file with something like wget. But the pnm: protocol doesn't work. Is there an offline program that can use this protocol?
I know one possibility is to redirect/dev/audio to a temporary file while using RealPlayer to "listen" to the files, but this is restricted to the take the full playback time, and worse, to be a full uncompressed audio file. I'd like to save the.ra files directly if possible.
On a related note, is RealAudioMP3 possible? Are there any utilities for manipulating Real files? Is the RealAudio format open?
Maybe now he'll really create Intertwingle. As much as I respect what he did at Mosaic/Netscape/Mozilla, my favorite JWZ creation has always been BBDB.
See JWZ's Excuse #1 (and 1a). The project is too big for someone to just come in and contribute something useful and small in a short amount of time. I think this has a lot of truth to it. It takes a while to figure out what's going on in even a medium-sized program, and Mozilla is huge.
One might say the same about the Linux kernel, but it's got a much longer history of being open.
> Yeah, that's not a compelling argument. ("simply > because existing tech exists").
The fact that there is an existing base of thousands of users already using a technology that works is not a compelling argument? Not to mention that a large part of the work is already done. I for one don't want to be constantly forced to change from a technology that's working.
This is not an argument against new formats, just saying that keeping old ones working is important. A better analogy than sticking with MS-DOS would be maintaining the ability to read MS-DOS disks.
New clients can support both formats, but till then proxies would be good.
Many vendor Unices (e.g. Solaris, IRIX) have been unbundling their C compilers in recent years, then charging often exorbanant fees for licencing. Hence some of the growth in popularity of gcc on these platforms. On IRIX, you don't even get NFS in the base package. You do pay for many of these commercial Unices (or at least for important components of them), and you keep paying.
I think the workstation manufacturers are desperately seeking revenue sources in the wake of an onslaught on the low end by Intel/Linux and other cheaper machines. The licensing stuff is prohibitive to individuals, though, and many corporate/acadamic users are starting to think of Linux as a real alternative in many cases as well, so I can't believe this is really in Sun/SGI's long term interest.
It is the anticompetitive part of the original post that I find most disturbing. Escient is trying to exclude applications from using another database if they use an official CDDB one.
They may have a right to protect their data (thogh the fact that it all came from volunteers doesn't give me too much sympathy for their ownership of it), and I don't really think it's unreasonable that applications display the CDDB logo while accessing the database, but this anticompetitive part is what's way out of line.
For the most part, I think Escient has been doing a good thing making the database freely available, and I don't begrudge them trying to make money on it. But if they are too obnoxious about it, we won't use it anymore.
OK, CDDB is not the perfect format. But it already works. I don't really believe that Escient has the legal ground to stand on here, particularly with regard to the format. It is based on xmcd, which is GPLed. They can't take that away. There are also older versions of the CDDB server which are GPLed, I believe. So if someone were to build a new database which uses CDDB format and solicited new contribution, I doubt that Escient could do a thing about. They might try, though, and the potential legal costs are likely to scare people away. That may be what they're counting on.
If someone wants to make a better format, fine, but anything that uses it ought to be backwards compatible with CDDB (which is one of the things Escient is trying to prevent happening). Then it could be pointed at either an "official" Escient CDDB server or a new database which uses the same protocol.
Where it could run into problems is from submitting entries which were downloaded from CDDB originally. It's not clear whether Escient can own those, but most CDDB users explicitly or implicitly agreed to their terms.
Anyway, my point is that backward compatibility is important. It should only be abandoned as a last resort. There are a lot of CDDB aware players out there already.
Basically Escient, though not trying to restrict user access to CDDB, is trying to strongarm developers of CD applications that use CDDB into complying with their terms, which include displaying the CDDB logo each time the CDDB is accessed and prohibiting the application from using any alternative databases.
It's not clear at all whether they actually own the contents or format of the database in any meaningful way, as the original program (xmcd) which used the protocol is GPLed, and the CDDB relies on user contributions to work. We made the database, now Escient wants to take it away.
Slashdot Mirror
Well, not quite. It is publicly funded, I believe most of the US support is from NIH. The Human Genome project is an international effort.
The conflict here (did you read the article?) is between the Genome project and a private company, Celera, which is racing to sequence and patent as much of the human genome as possible before the Human Genome project does. The two have been in talks to assimilate the data into a single database, but they seem to be hung up on intellectual property issues.
Baloney. Software still sucks. Systems have to get a lot better. That means better for everyone, from beginning to expert users.
Although I agree that total control should be there, it doesn't mean that out-of-the-box settings have to be difficult to use.
I think you missed my point here. I don't want to support these OSes. I just want the standards that people are using on the internet to be open. Then if someone cares, they can port something to whatever operating system they happen to like using.
Personally, I'm sad to see support for Unix systems (other than Linux x86) declining. RealPlayer is still at version 5 for most Unix platforms. I don't really care on a personal level whether BeOS (for example) has the latest and greatest support for audio streaming. But I don't think that a smaller niche OS should be prevented from using a particular internet standard just because it isn't in the interest of a particular company to develop a client for that platform. That's the major problem with proprietary formats, and I don't think Linux users should be placated by the extension of this closed format to the x86 platform. Everyone else still gets left behind.
And not just Linux non-x86 platforms are left out: so are other Unices, not to mention other OSes like BeOS and OS/2.
The Linux community is often guilty of the same assumptions that they so deplore in Windows users: that everyone uses the same as they do. Just as "computer" means a Windows-based PC to most people, "Linux" means Linux-x86 to most users. And they can be somewhat blind to those other operating systems with smaller user bases.
I don't think the RedHat-Real partnership is necessarily a bad thing. It's an OK thing. But it may take our eyes away from some more important goals: real freedom of choice and transparent interoperability. For this, we need real open standards (an open Real standard would be nice). Streaming media at the moment is essentially a contest between two closed, proprietary formats, and not only will neither company do the work to port their clients (not to mention servers) to OSes with a smaller user base (Redhat Linux x86 apparently has made the threshold now), but because the formats themselves are closed, no one else could do it if they wanted to.
Open standards are essential. Open source implementations can come next.
The outside limit of the shuttle's maximum landing payload is about 50,000 pounds. With gold at about $300 per troy ounce, that's about $220 million in bullion you could bring back, if it was already hanging around in low earth orbit.
You still lose plenty. Or rather, the taxpayers do.
PS Sorry about the lame units, that's how NASA gives the numbers. And gold is always troy ounces.
I agree completely, neither vi nor emacs has a very intuitive interface. But I would argue that both have very efficient interfaces for experienced users. Yes, the learning curve is steeper. But once you have made it a good way up the curve, you can get things done much, much faster than you could in any more "intuitive" interface.
I have nothing against easy-to-learn applications, they should exist for people who prefer them, but "expert" level interfaces like vi and emacs can't be beat for getting complex tasks done very quickly.
When is the last time a new major version release ever led to "a more stable and faster Netscape"? It just gets slower and more bloated with every upgrade. I kept using 3.0 for as long as possible before upgrading to the 4.x series. But nowadays, too many things require version 4 browsers.
Perhaps Mozilla is the only hope for a non-Microsoft broswer, I don't know. But I don't plan to upgrade until there is a browser actually working that is in fact both faster and more stable. I have little expectation that this will be Netscape Navigator 5.0.
The soundtrack to the novel was indeed Nick Cave, it seems. I heard William Gibson on the BBC Radio 4 program "Desert Island Discs" this morning, in which he chose the 8 records he would get to have with him if stranded on a desert island. One was Nick Cave's "Are You the One I've Been Looking For", which was also his top choice if he had to narrow it down to one disc only.
Another of the songs was an early demo of "All Tomorrow's Parties" by Velvet Underground. He also picked another John Cale song, performed by someone else. The remaining 5 tracks were by Doc Boggs, Steely Dan, Bruce Springsteen, Tom Waits and Taj Mahal. It was a great program, and I even looked around to see if it was archived on the web but had no luck. Anyone know if the Beeb has RealAudio archives of programs like this somewhere?
Same for me to the French language Lycos site.
First of all, it's odd for me, a native English speaker who happens to be living in France, to be automatically redirected to a French language page. But it starts getting to be annoying when I start out on the English page, search for Excite and end up on their Excite redirection page, which is back in the Lycos.com domain, do a search with the link on that page, and end up on the French language home page anyway!
Granted, it's hard for an English speaker to complain about the language content of the web (which must still be 90% English), but sheesh! If I start out specifying the language, shouldn't I at least stay in that language? Especially if it happens to be the original language of the site.
Massachusetts has called itself a Commonwealth at least since 1780, back when the "Commonwealth" you refer to was still the British Empire, and would be for some time to come.
Their home page is up now, too.
Use the LinuxHQ slashbox. It's exactly what you're talking about.
I completely fail to see how filtering of one's own choosing is bad. OK, I agree that it can possibly border on censorship if it's not your own doing, but then again, it can just be good editing. If I want to read content that's been checked and edited and filtered, I'll read the NY Times or equivalent. If I don't, I'll read Usenet. Guess which one I read more often. Slashdot is great because we can choose exactly how we want to do the filtering. So some people don't want to read Jon Katz - why is it worse to have him automatically not listed than just to skim over and not click the titles? It's still their choice.
One thing the web shows again and again is the importance of editors. I think they will become more, not less, important in the future. We can't read everything, and it's good to have ways to choose what's important. Sometimes it will be a real person (or people), sometimes it will be a team of moderators and/or user preferences, like Slashdot.
More choice is good. So are more ways to find the things we actually want to take the time to read.
Naturally if the files are encoded at the same bitrate, (e.g. 128kbps) they will have (approximately) the same size. What they are arguing is that the M$ format sounds slightly better at about half the bits/second.
I don't know whether it's true, I haven't heard it, but that's what they're claiming. So encode an MP3 at 128kbps and a M$ format file at 64kbps and see what you get.
One of the results from all these searches that I would think would be most interesting is the number of stars that apparently _do not_ have planets (within the limits of resolution, of course) relative to the number that do. I've never seen that talked about in any of the popular press reports or even the general articles in Nature or Science. Perhaps the astronomy literature deals with the question.
By now, with so many of these systems known, shouldn't we be able to start taking stabs at the statistics of solar system formation, at least for Jupiter-sized planets and up?
Anyone know?
This is a bit off topic, but here goes:
.ram (or .rmm) file with something like wget. But the pnm: protocol doesn't work. Is there an offline program that can use this protocol?
/dev/audio to a temporary file while using RealPlayer to "listen" to the files, but this is restricted to the take the full playback time, and worse, to be a full uncompressed audio file. I'd like to save the .ra files directly if possible.
Is there a good solution for offline RealAudio? What I'd really like to do is slurp down files listed in a
I know one possibility is to redirect
On a related note, is RealAudioMP3 possible? Are there any utilities for manipulating Real files? Is the RealAudio format open?
Maybe now he'll really create Intertwingle. As much as I respect what he did at Mosaic/Netscape/Mozilla, my favorite JWZ creation has always been BBDB.
See JWZ's Excuse #1 (and 1a). The project is too big for someone to just come in and contribute something useful and small in a short amount of time. I think this has a lot of truth to it. It takes a while to figure out what's going on in even a medium-sized program, and Mozilla is huge.
One might say the same about the Linux kernel, but it's got a much longer history of being open.
> Yeah, that's not a compelling argument. ("simply
> because existing tech exists").
The fact that there is an existing base of thousands of users already using a technology that works is not a compelling argument? Not to mention that a large part of the work is already done. I for one don't want to be constantly forced to change from a technology that's working.
This is not an argument against new formats, just saying that keeping old ones working is important. A better analogy than sticking with MS-DOS would be maintaining the ability to read MS-DOS disks.
New clients can support both formats, but till then proxies would be good.
Many vendor Unices (e.g. Solaris, IRIX) have been unbundling their C compilers in recent years, then charging often exorbanant fees for licencing. Hence some of the growth in popularity of gcc on these platforms. On IRIX, you don't even get NFS in the base package. You do pay for many of these commercial Unices (or at least for important components of them), and you keep paying.
I think the workstation manufacturers are desperately seeking revenue sources in the wake of an onslaught on the low end by Intel/Linux and other cheaper machines. The licensing stuff is prohibitive to individuals, though, and many corporate/acadamic users are starting to think of Linux as a real alternative in many cases as well, so I can't believe this is really in Sun/SGI's long term interest.
Graham Toal wrote:
> Competition never hurt anybody.
It is the anticompetitive part of the original post that I find most disturbing. Escient is trying to exclude applications from using another database if they use an official CDDB one.
They may have a right to protect their data (thogh the fact that it all came from volunteers doesn't give me too much sympathy for their ownership of it), and I don't really think it's unreasonable that applications display the CDDB logo while accessing the database, but this anticompetitive part is what's way out of line.
For the most part, I think Escient has been doing a good thing making the database freely available, and I don't begrudge them trying to make money on it. But if they are too obnoxious about it, we won't use it anymore.
OK, CDDB is not the perfect format. But it already works. I don't really believe that Escient has the legal ground to stand on here, particularly with regard to the format. It is based on xmcd, which is GPLed. They can't take that away. There are also older versions of the CDDB server which are GPLed, I believe. So if someone were to build a new database which uses CDDB format and solicited new contribution, I doubt that Escient could do a thing about. They might try, though, and the potential legal costs are likely to scare people away. That may be what they're counting on.
If someone wants to make a better format, fine, but anything that uses it ought to be backwards compatible with CDDB (which is one of the things Escient is trying to prevent happening). Then it could be pointed at either an "official" Escient CDDB server or a new database which uses the same protocol.
Where it could run into problems is from submitting entries which were downloaded from CDDB originally. It's not clear whether Escient can own those, but most CDDB users explicitly or implicitly agreed to their terms.
Anyway, my point is that backward compatibility is important. It should only be abandoned as a last resort. There are a lot of CDDB aware players out there already.
See the recent /. article on this.
Basically Escient, though not trying to restrict user access to CDDB, is trying to strongarm developers of CD applications that use CDDB into complying with their terms, which include displaying the CDDB logo each time the CDDB is accessed and prohibiting the application from using any alternative databases.
It's not clear at all whether they actually own the contents or format of the database in any meaningful way, as the original program (xmcd) which used the protocol is GPLed, and the CDDB relies on user contributions to work. We made the database, now Escient wants to take it away.