Rambus uses less connections/chip, so it can be packaged smaller, and more channels per chip can be used - the PS2 uses 4 channels of RDRAM for 3.2 GB/s of bandwidth, using fewer pins than the 1.066 GB/s PC133 SDRAM bus in most PC's. Fewer pins means fewer traces and that makes boards cost less. It was the only way that Sony could get the bandwidth it needed for the PS2 while still staying in budget.
The N64 uses an early form of RDRAM as well, one of the first uses of the technology.
It's not that it's bad technology, just misapplied to PC's when supply was not availible,and managed by a company with a overzealous legal department.
The differences between the US and Japanses PS2's are that the US has a drive bay in the back for a hard disk/ ethernet card instead of the PCMCIA slots that the Japanese one had, and the US one has the DVD playing software in ROM instead of as a file on the memory card, so it can't be corrupted by games, which was a big fiasco over there (Ridge Racer broke the DVD player when it saved). Cool that you can execute stuff off the memory card though...
It still decodes in software, it's just that the software is in ROM, not on the memory card.
The PS2 has a TOSLINK (optical digital) on the back for digital audio and can do AC3 and DTS out to an external decoder just fine.
It's in the specs somewhere. Games will be able to use this as well - it'll be nice to have full home theatre surround instead of the tinny 4 speaker setups that most PC surround sound is today.
Because they're stroke based and fairly formalized font faces, it's easier to do OCR on Asian languages. For example, Japanese Kanji are made up
of 150 or so drawings, combined in different ways to make the 6000 or so kanji as a whole (2500 commonly used). Recognize the 150 (which are usually 2-3 strokes total, and easier than recognizing the 54 english letters for both upper and lowercase) and you're set.
Handwriting recognition is easier as well - set stroke orders make it easy to recognize which character is being written. Theres a Unix program out there that does it IIRC.
One word refutation: Metroid (if you look past the fact that you can't tell for most of the game)
For the most part, you're right. I think the system couldn't support many of the things that appeal to women today in video games, such as deep character development and graphics. The stereotyping and such is bad, but for the most part it's stopped.
Also, remember that many of the games were made by japanese developers, whose only experience with minorities is in foreign movies and TV (Japan being 98% racially pure and all). So what you're seeing is the way the rest of the world represents minorities in the media through the eyes of japanese game developers.
I haven't done DVD -> SVCD under linux, but I have made VCD's and SVCD's from video files I captured with my BUZ card.
The VCD tools (for making VCD images) are availible from here:
http://www.munich-vision.de/vcd/index.html
As for the conversion and DVD issues, anyone else have suggestions?
You may just want to stick with Windows for this - the best encoders are there (Tsunami is great!), and the process is quite a bit more streamlined on that side.
All this piece really says is that developers and packagers need to do a better job of keeping dependancy lists and such in good order. RPM has some great features, and Redhat has made a lot of progress on it feature wise - version 3 is far better than previous versions, and includes the pre and post install script capability as described in article.
I see this as less of a problem with RPM and more of a problem with developers. This is not to say that RPM couldn't be improved - it could run ldd or some such library dependancy program on binaries to help out the situation, or some modified version of strace that checks to see which files it accesses, but in the end it falls to the developer and packager to make sure that the package is works correctly and lacks dependancy problems.
So, it's having a chip that can turn off parts of itself when they aren't needed. Lots of processors today do that. Lots of processors change their speeds to cut power as well. They don't cut their cache sizes though, which this is proposing. It makes sense though - the cache has to be on all the time to keep from losing data, but why couldn't you get about the same effect with today's processors by making them flush their caches and power them off when going into a low power state? Of course, this technology would allow you to work at the same time, at a lower speed, but the full power on time of a microprocessor today is measured in nanoseconds - you wouldn't even notice it. Loading from memory may take a bit longer, but it's still not noticeable, except in artificial tests.
As for the speed increase aspect of it, I doubt that this tech can turn L1 and L2 caches into each other - it probably can just cut the sizes of each - so leaving them all the way on all the time would give you them best performance - and of the power saving features would at best change nothing.
Sounds like a neat idea though, but the proof will be in the implementation .
DivX is a real hack of a standard - basically, it's just a leaked version of the MPEG 4 codec from Microsoft, and a MP3 audio stream. You need a pretty fast computer to decode it, and it's only decodable on computer. I personally would rather use my nice big TV to watch movies.... SVCD is far better in my opinion - it offers most of the features of DVD (menus, overlayed subtitles, multiple audio tracks), and nearly every DVD player out there will play an SVCD. SVCD compression isn't as good as DivX (space wise, not quality, which depends on the encoder). SVCD is MPEG 2 compression which is fairly standard across all computers - the DivX codec on the only linux player is a hack on the Windows codec, making it x86 only. DivX seems like a fad to me - the codec is so new and not standardized that I doubt it'll last too long before the next fad compression technology comes out. Seems like the old audio compression format battles of a couple years ago - the open standard (mp3) prevailed over others (AAC,.rm, etc)
Slashdot needs an Anime subject heading instead of just lumping all the anime news in with entertainment news. I like the coverage, but there are quite a few people out there who would like to opt out of the coverage, just like they opt out of other subjects.
Although it's a huge infringment on our rights, legislation like this can only help the free software community.
If people are given a choice between software that truly belongs to them which they have full control over and being led around on a leash by corporate interests that have goals other than their own, they'll pick freedom every time. Free software will take off because it will become the only way people can get what they really want and need. Projects like KDE and Gnome are coming along to the point where switching from other OS's is an extremely viable solution.
That said, it's sad to see developments like this. When it comes down to it, it's greed and powermongering at it's worst.
Cowboy Bebop is one of the better Anime series to come out in a while. Good storyline, funny, good action scenes. Not too much gratuitous sex or gory violence. Definitely worth renting. Props to Bandai for making it a 5 TV episode/DVD release.
That said, MI2 is all about style. But it's copied style - they took the Matrix and Face Off, and added a cheezy sub-Bond movie plot. I mean halfway through they have a guy EXPLAIN the plot. Not worth seing, unless you don't care about any semblance of a story.
The graphics chipsets are just tuned nVidia Geforce, Quadro, and Geforce 2 boards, which is what SGI told everyone at SGI Linux University. Uses closed source drivers, jointly developed with nVidia.
They also said that some special tweaks would be put on their boards so that they would run faster than generic cards with identical drivers. Other than a mild overclocking (to get the higher fill rate listed), I don't see any way they could do this than to minorly cripple the drivers for boards that don't have official SGI roms.
That said, it's nice to see SGI making progress towards high quality 3D on Linux - I just wish they weren't following the propreitary lead of nvidia.
As anyone who has used it knows, the dreamcast controller does not have the secondary trigger buttons that are on a playstation controller, or one of the dual shock's analog sticks (which are far better than the "rip the skin of your finger" stick on the dreamcast).
What does your future roadmap for SCO unix look like? - Are you going the SGI path and gradually phasing out your own Unix in favor of Linux, or are you pursuing a parallel development path of both OSs?
What features currently in SCO that are not in Linux do you feel are necessary for wider corporate acceptance of Linux?
I went to the "SGI Linux University" a couple weeks back in Tucson, and they had a security segment at it, in which they described adding C2 and B1 level security to linux, and what would be required. They're probably a good company to do it, seeing as they have a lot of experience with Trusted IRIX. It's also prohibitively expensive to get the actual testing done, and having a big company foot the bill is very important.
The greatest strength of open source - fast development time - is a burden on secure systems. Everytime something is changed, the whole needs to be reanalyzed so that no security breaches are created by the change. This is why pro-security distributions like OpenBSD are still using BIND 4.X and such - they don't have the time to reverify all the new packages and revisions.
That said, certification means little until tested in the real world, but it can definitely help - look at OpenBSD's record!
I agree that there will be a turning point - but in our favor.
People have an innate preference to share with others when it benefits them. This is why Free Software works, and why programs like Napster and other file sharing protocols work. Same cause, although different legalitiy...
IMHO, people follow their instincts. Most intellectual property laws follow against people's instincts, and the only think that protected them in the past was the copying cost (ie for books and movies that cost a lot to copy on paper and film).
We're going to see legal disobedience on a large scale, on the basis of what comes naturally. You can't fight that , no matter how many laws you make. Even then, smart people will find a way - they always have and always will.
So, in the end, producing Intellectual Property isn't going to make any money. All jobs will be service jobs - people are paid to create for a specific purpose or situation (like doctors and scientists and sysadmins are paid today).
Where do you see Samba headed in the future, other than to be more compatible with Windows servers and clients? Higher levels of security (read encryption) between Samba only servers?
I've seen many setups using Samba as an extra level of security in the DMZ of a firewall - using the SMB protocol to keep data synchronized instead of normal Unix file transfer protocols (ie ftp or nfs) that are better known to the cracker community.
The guy who registered openssh.org runs the zedz.net site, which hosts the replay redhat crypto archives (good place to get.rpms of security software). They used to be at replay.com before replaytv bought the domain from them.
The Zedz guys seem to be pretty good people as far as free software goes. Makes you wonder what they plan to do with the domain, and why they set it up as a forwarder to openssh.com
This reminds me of the whole LinuxHQ/Kernelnotes.org fiasco...
As of now, Precision insight is working on DRI for 3dfx and ATI 128 cards, for inclusion in XF86 4.
The Utah GLX project has working under the XF85 3.3.X series writing drivers for Matrox, ATI Rage, S3 Virge, Nvidia, and i810 cards, outside the DRI framework. These will need to be converted to DRI to be included XFree86 4.
As far as FreeBSD goes, the new module loader will allow you to run the same of XF86 4 module on any OS, as long as it uses the same processor. So x86 Linux modules will run on FreeBSD without a recompile. Pretty cool huh!
At my work, we got a bunch of new solaris boxes. Solaris has a pretty nice install, and is decently polished out of the box. On the flipside, it is missing a lot of things people take for granted if you come from the Linux or *BSD world, like gcc, perl and apache.
On a sour note, I had a bad experience with Solaris 7. If you wanted to set up diskless clients, you were out of luck - out of the box, setting them up was broken. To get the patch, you had to have a service contract with Sun (ie lots of money!) and then search for it for quite a while. It wasn't in any of the free patchsets they distribute over the net - its like buying a car and then having to pay the dealer to fix something that was wrong with it when you bought it! This really sucks - documentation and fixes should be free!
Solaris 8 supposedly has a lot of GNU tools (including the ones mentioned above). They're finally getting a clue it looks like....
Slashdot Mirror
Rambus uses less connections/chip, so it can be packaged smaller, and more channels per chip can be used - the PS2 uses 4 channels of RDRAM for 3.2 GB/s of bandwidth, using fewer pins than the 1.066 GB/s PC133 SDRAM bus in most PC's. Fewer pins means fewer traces and that makes boards cost less. It was the only way that Sony could get the bandwidth it needed for the PS2 while still staying in budget.
The N64 uses an early form of RDRAM as well, one of the first uses of the technology.
It's not that it's bad technology, just misapplied to PC's when supply was not availible,and managed by a company with a overzealous legal department.
BBK
The differences between the US and Japanses PS2's are that the US has a drive bay in the back for a hard disk/ ethernet card instead of the PCMCIA slots that the Japanese one had, and the US one has the DVD playing software in ROM instead of as a file on the memory card, so it can't be corrupted by games, which was a big fiasco over there (Ridge Racer broke the DVD player when it saved). Cool that you can execute stuff off the memory card though...
It still decodes in software, it's just that the software is in ROM, not on the memory card.
BBK
The PS2 has a TOSLINK (optical digital) on the back for digital audio and can do AC3 and DTS out to an external decoder just fine.
It's in the specs somewhere. Games will be able to use this as well - it'll be nice to have full home theatre surround instead of the tinny 4 speaker setups that most PC surround sound is today.
Because they're stroke based and fairly formalized font faces, it's easier to do OCR on Asian languages. For example, Japanese Kanji are made up
of 150 or so drawings, combined in different ways to make the 6000 or so kanji as a whole (2500 commonly used). Recognize the 150 (which are usually 2-3 strokes total, and easier than recognizing the 54 english letters for both upper and lowercase) and you're set.
Handwriting recognition is easier as well - set stroke orders make it easy to recognize which character is being written. Theres a Unix program out there that does it IIRC.
BBK
Yay! Now they can have one more sailor senshi on Sailor Moon!
Or not...
BBK
One word refutation: Metroid (if you look past the fact that you can't tell for most of the game)
For the most part, you're right. I think the system couldn't support many of the things that appeal to women today in video games, such as deep character development and graphics. The stereotyping and such is bad, but for the most part it's stopped.
Also, remember that many of the games were made by japanese developers, whose only experience with minorities is in foreign movies and TV (Japan being 98% racially pure and all). So what you're seeing is the way the rest of the world represents minorities in the media through the eyes of japanese game developers.
BBK
I haven't done DVD -> SVCD under linux, but I have made VCD's and SVCD's from video files I captured with my BUZ card.
The VCD tools (for making VCD images) are availible from here:
http://www.munich-vision.de/vcd/index.html
As for the conversion and DVD issues, anyone else have suggestions?
You may just want to stick with Windows for this - the best encoders are there (Tsunami is great!), and the process is quite a bit more streamlined on that side.
BBK
All this piece really says is that developers and packagers need to do a better job of keeping dependancy lists and such in good order. RPM has some great features, and Redhat has made a lot of progress on it feature wise - version 3 is far better than previous versions, and includes the pre and post install script capability as described in article.
I see this as less of a problem with RPM and more of a problem with developers. This is not to say that RPM couldn't be improved - it could run ldd or some such library dependancy program on binaries to help out the situation, or some modified version of strace that checks to see which files it accesses, but in the end it falls to the developer and packager to make sure that the package is works correctly and lacks dependancy problems.
BBK
So, it's having a chip that can turn off parts of itself when they aren't needed. Lots of processors today do that. Lots of processors change their speeds to cut power as well. They don't cut their cache sizes though, which this is proposing. It makes sense though - the cache has to be on all the time to keep from losing data, but why couldn't you get about the same effect with today's processors by making them flush their caches and power them off when going into a low power state? Of course, this technology would allow you to work at the same time, at a lower speed, but the full power on time of a microprocessor today is measured in nanoseconds - you wouldn't even notice it. Loading from memory may take a bit longer, but it's still not noticeable, except in artificial tests.
As for the speed increase aspect of it, I doubt that this tech can turn L1 and L2 caches into each other - it probably can just cut the sizes of each - so leaving them all the way on all the time would give you them best performance - and of the power saving features would at best change nothing.
Sounds like a neat idea though, but the proof will be in the implementation .
DivX is a real hack of a standard - basically, it's just a leaked version of the MPEG 4 codec from Microsoft, and a MP3 audio stream. You need a pretty fast computer to decode it, and it's only decodable on computer. I personally would rather use my nice big TV to watch movies.... SVCD is far better in my opinion - it offers most of the features of DVD (menus, overlayed subtitles, multiple audio tracks), and nearly every DVD player out there will play an SVCD. SVCD compression isn't as good as DivX (space wise, not quality, which depends on the encoder). SVCD is MPEG 2 compression which is fairly standard across all computers - the DivX codec on the only linux player is a hack on the Windows codec, making it x86 only. DivX seems like a fad to me - the codec is so new and not standardized that I doubt it'll last too long before the next fad compression technology comes out. Seems like the old audio compression format battles of a couple years ago - the open standard (mp3) prevailed over others (AAC, .rm, etc)
Slashdot needs an Anime subject heading instead of just lumping all the anime news in with entertainment news. I like the coverage, but there are quite a few people out there who would like to opt out of the coverage, just like they opt out of other subjects.
BBK
Although it's a huge infringment on our rights, legislation like this can only help the free software community.
If people are given a choice between software that truly belongs to them which they have full control over and being led around on a leash by corporate interests that have goals other than their own, they'll pick freedom every time. Free software will take off because it will become the only way people can get what they really want and need. Projects like KDE and Gnome are coming along to the point where switching from other OS's is an extremely viable solution.
That said, it's sad to see developments like this. When it comes down to it, it's greed and powermongering at it's worst.
BBK
you're right.. I mistyped. It's $2.50 an encoder, $0.50 a decoder. Sorry 'bout that.
Oh, and they also want to charge $0.50 per decoder... Looks like winamp and others are going to be in hot water too...
Fraunhoffer and Thompson recently changed their licensing policy - you can read the new version here: http://www.mp3licensing.com/index.html
Basically, it's like $2.50 per player, minimum of $15,000 per product. Quite a lot for any project.
Cowboy Bebop is one of the better Anime series to come out in a while. Good storyline, funny, good action scenes. Not too much gratuitous sex or gory violence. Definitely worth renting. Props to Bandai for making it a 5 TV episode/DVD release.
That said, MI2 is all about style. But it's copied style - they took the Matrix and Face Off, and added a cheezy sub-Bond movie plot. I mean halfway through they have a guy EXPLAIN the plot. Not worth seing, unless you don't care about any semblance of a story.
The graphics chipsets are just tuned nVidia Geforce, Quadro, and Geforce 2 boards, which is what SGI told everyone at SGI Linux University. Uses closed source drivers, jointly developed with nVidia.
They also said that some special tweaks would be put on their boards so that they would run faster than generic cards with identical drivers. Other than a mild overclocking (to get the higher fill rate listed), I don't see any way they could do this than to minorly cripple the drivers for boards that don't have official SGI roms.
That said, it's nice to see SGI making progress towards high quality 3D on Linux - I just wish they weren't following the propreitary lead of nvidia.
As anyone who has used it knows, the dreamcast controller does not have the secondary trigger buttons that are on a playstation controller, or one of the dual shock's analog sticks (which are far better than the "rip the skin of your finger" stick on the dreamcast).
Aftermarket controllers anyone?
What does your future roadmap for SCO unix look like? - Are you going the SGI path and gradually phasing out your own Unix in favor of Linux, or are you pursuing a parallel development path of both OSs?
What features currently in SCO that are not in Linux do you feel are necessary for wider corporate acceptance of Linux?
I went to the "SGI Linux University" a couple weeks back in Tucson, and they had a security segment at it, in which they described adding C2 and B1 level security to linux, and what would be required. They're probably a good company to do it, seeing as they have a lot of experience with Trusted IRIX. It's also prohibitively expensive to get the actual testing done, and having a big company foot the bill is very important.
The greatest strength of open source - fast development time - is a burden on secure systems. Everytime something is changed, the whole needs to be reanalyzed so that no security breaches are created by the change. This is why pro-security distributions like OpenBSD are still using BIND 4.X and such - they don't have the time to reverify all the new packages and revisions.
That said, certification means little until tested in the real world, but it can definitely help - look at OpenBSD's record!
I agree that there will be a turning point - but in our favor.
People have an innate preference to share with others when it benefits them. This is why Free Software works, and why programs like Napster and other file sharing protocols work. Same cause, although different legalitiy...
IMHO, people follow their instincts. Most intellectual property laws follow against people's instincts, and the only think that protected them in the past was the copying cost (ie for books and movies that cost a lot to copy on paper and film).
We're going to see legal disobedience on a large scale, on the basis of what comes naturally. You can't fight that , no matter how many laws you make. Even then, smart people will find a way - they always have and always will.
So, in the end, producing Intellectual Property isn't going to make any money. All jobs will be service jobs - people are paid to create for a specific purpose or situation (like doctors and scientists and sysadmins are paid today).
We're going to win. It's just a matter of time.
-BBK
Where do you see Samba headed in the future, other than to be more compatible with Windows servers and clients? Higher levels of security (read encryption) between Samba only servers?
I've seen many setups using Samba as an extra level of security in the DMZ of a firewall - using the SMB protocol to keep data synchronized instead of normal Unix file transfer protocols (ie ftp or nfs) that are better known to the cracker community.
The guy who registered openssh.org runs the zedz.net site, which hosts the replay redhat crypto archives (good place to get .rpms of security software). They used to be at replay.com before replaytv bought the domain from them.
The Zedz guys seem to be pretty good people as far as free software goes. Makes you wonder what they plan to do with the domain, and why they set it up as a forwarder to openssh.com
This reminds me of the whole LinuxHQ/Kernelnotes.org fiasco...
As of now, Precision insight is working on DRI for 3dfx and ATI 128 cards, for inclusion in XF86 4.
The Utah GLX project has working under the XF85 3.3.X series writing drivers for Matrox, ATI Rage, S3 Virge, Nvidia, and i810 cards, outside the DRI framework. These will need to be converted to DRI to be included XFree86 4.
As far as FreeBSD goes, the new module loader will allow you to run the same of XF86 4 module on any OS, as long as it uses the same processor. So x86 Linux modules will run on FreeBSD without a recompile. Pretty cool huh!
At my work, we got a bunch of new solaris boxes. Solaris has a pretty nice install, and is decently polished out of the box. On the flipside, it is missing a lot of things people take for granted if you come from the Linux or *BSD world, like gcc, perl and apache.
On a sour note, I had a bad experience with Solaris 7. If you wanted to set up diskless clients, you were out of luck - out of the box, setting them up was broken. To get the patch, you had to have a service contract with Sun (ie lots of money!) and then search for it for quite a while. It wasn't in any of the free patchsets they distribute over the net - its like buying a car and then having to pay the dealer to fix something that was wrong with it when you bought it! This really sucks - documentation and fixes should be free!
Solaris 8 supposedly has a lot of GNU tools (including the ones mentioned above). They're finally getting a clue it looks like....