Red Hat Inc. will cease to use the "Red Hat" label on its free distribution (previously known as "Red Hat Linux"), and continue using it exclusively on its paid-for distribution (a.k.a. RHEL - "Red Hat Enterprise Linux"). "Red Hat Linux" will become "Fedora Linux", and RHEL will continue to be the paid-for distribution.
Neither of these distributions will change in its inner core and/or "philosophy", with one exception: Red Hat will loose its grip a little bit on Fedora (previously known as "Red Hat Linux"), which will become more open. Think of it as a combination between the old Red Hat Linux, and a non-corporate free Unix distribution such as Debian or FreeBSD. Otherwise, the core of the development effort on Fedora will continue to be provided by Red Hat - hence the term "Fedora Core" used for the releases. Essentially, Red Hat expects to continue as before with the development of the distribution, it's just that they opened the doors for contributions from outside related to packages of a secondary importance.
In fact, future versions of the paid-for RHEL will actually be older branches of Fedora Linux, plus proprietary additions by Red Hat Inc.
The older RH Linux versions (6.x, 7.x, 8) will become unsupported by Red Hat on Dec 31 2003, while RHL 9 will continue to be supported until Apr 30 2004. "Unsupported" meaning that Red Hat will not provide updates anymore. That's normal, and in fact it was amazing they continued to support 6.x for so long.
Fedora Linux will get a mixed support model: Red Hat will support Fedora releases for limited amounts of time (shorter than the lifetime of the 6.x releases anyway!), together with support from the community built around the Fedora Project (a la Debian); once the "official" Red Hat support for a certain Fedora version disappears, its the community support that will continue to provide updates for it. My estimate is that the support provided by the community will actually last for a lot longer than the "official" support - see the case of the non-corporate Unix distributions such as Debian, FreeBSD, etc. which are supported for long periods of time.
Obviously, Red Hat is trying to draw as much attention as they can to their RHEL product, which is where their money come from. But i feel that, during this whole change, their "market droids" did a poor job of explaining what's really going on. Hence the rumors that "Red Hat Linux goes away, everyone must buy RHEL or migrate to something else" etc. Oh wait, but then they did a _good_ job!:-)
Fedora Core 1 (or "the distribution formerly known as Red Hat Linux 10") is scheduled for release this week.
Yes. It's called Chain Reaction. It has several deinterlace algorithms, unsharp, denoise, resize, some other filters borrowed from TVtime (that's another very cool media application), etc.
a problem specifically with Xine's, and it's independent of skin. Buttons mysteriously stop working
I hope you're not insinuating that mplayer is faultless. It regularly has issues with full-screen mode, on several different Linux distributions. It loses A/V sync when playing DVDs more easily than any other popular DVD player (Xine, Ogle). etc. I'm not saying that Xine is faultless either. But AFAICT, there's no clear "winner" in the crashing contest.
I also have a problem with the fact that Xine's volume button is independent of the mixer device. MPlayer uses the mixer directly, so if my wife watches a movie with MPlayer, and turns the volume down so it doesn't wake up the baby, then I have to open aumix (or another mixer) to restore the volume for Xine to play the sound audibly.
You probably never saw the "restore volum level at startup" option in xine. But since you said you never read the docs, it's not surprising.
my comment wasn't uninformed. I was trying to provide what I had experienced to another poster
I can see that, but you didn't present the information as personal experience (in that case it would have been ok), but as objective truths (which it wasn't). Hence my (arguably rough) tone.
Xine takes about 5 seconds to start up when you click on a movie file. MPlayer starts up in less than 1 second
I do agree with you that Xine takes a bit longer to start than mplayer. But in my experience the ratio is more like 3/2 not 5/1. Either you're exagerating, or something on your system is very different than on mine.
If it weren't for the tone of your post, I'd probably be more inclined to--as you say--read the docs for Xine, but I must say that you have completely failed to convince me I should bother
Not a big loss, from what i can see.
I've never even seen docs for Xine
You probably keep your eyes tightly shut, or read very selectively, otherwise i can't explain how you can miss the big honking Documentation link on their webpage.
So much for objective comments...
Re:CPU usage with Xine, mplayer, etc.
on
Mplayer Revisited
·
· Score: 1
I almost exclusively use the text-only mplayer. That is, when i do use it, because usually it's Xine which plays my media files.
Mplayer is not a particularly great choice for non-techies
Well, as long as you install the GUI, it should be quite usable by non-techies as well.
mplayer [...] is faster than anything else in existence
Actually, if you look at objective reports, you'll see that reality is a bit different. Quite a few people (non-biased observers) report that mplayer is by no means the fastest player available. E.G. on my system (AthlonXP/1800, GeForce2) actually it's Xine which has the lowest CPU usage almost any time.
Also, the "ours is the fastest player ever" is the most useless bit of the mplayer propaganda. If your CPU usage is below 5% no matter what's the player, who cares what's the "fastest" player. In my case, mplayer has a slightly higher CPU usage (and i did follow the build instructions to the letter) but that doesn't prevent me from using it every now and then (but in most cases i use Xine, especially when it comes to DVDs, since it has a far better DVD support - it can handle DVD menus properly).
mplayer [...] has support for just about every interface and codec under the sun
We mustn't forget that Xine plays all those formats as well. It's only a matter of installing the right codecs (Win32, Real, etc.).
The browser plugin included in the gxine GUI is trivial to install, just copy the right file into the Mozilla plugins directory (or your browser's plugins directory if you're not using Mozilla). No issues whatsoever, neither on my system, nor reported by other users on the mailinglist.
xine-0.9.13 (the last version in the previous "stable" series) indeed had some stability issues. But you may try the latest pre-1.0 release, it seems to be rock stable. Also, if you install the Win32 codecs and Real, it plays all the formats supported by mplayer. Not to mention that DVD support is more evolved in Xine (handles DVD menus, etc.)
CPU usage with Xine, mplayer, etc.
on
Mplayer Revisited
·
· Score: 1
Indeed, i noticed the same thing. On my system (AthlonXP/1800, GeForce2, Red Hat 9) i constantly get lower CPU usage from Xine than from mplayer, even though the mplayer documentation is so proud about their supposed "lowest" CPU usage among all players. It's actually funny...
advantage I have with Mplayer is actually it's keyboard interface
You can control xine-ui with keyboard shortcuts as well. Moreover, there is a text-mode interface that you can use if you don't like the GUIs. Read the docs before making uninformed comments.
MPlayer also has the ability to specify video and sound drivers on the command line. Xine may have it
Xine does have it. It's the -V and -A switches. Please read the docs.
Xine is GUI oriented
No. Xine is a library, not a player. Whatever interface you build on top of it, it's your decision, Xine doesn't care. Indeed, the existing interfaces seem to generally be oriented towards GUI, but there is at least one text-mode interface.
The biggest plus to using mplayer [...] comes when you associate it with the file extensions
That's ridiculous. You can associate extensions with any player, and the results are similar.
Re:or take a look at Xine
on
Mplayer Revisited
·
· Score: 2, Informative
it doesn't seem to support all the same formats that mplayer does [...] Xine doesn't play.asf files
If you install the Win32 codecs, Xine will happily play all those formats you mention.
I've a few mpg's that mysteriously don't play on xine
I've a few mpg's that not misteriously don't play but on one of the players that i use (xine, VLC, mplayer...) and on none of the other. The "mplayer plays all files that other players won't play" myth is just that: a myth. You will always find files that are not playable on all players (or even worse, are playable on only one player).
mplayer renders much more sharply and clearly than xine
You are probably not using the Xv mode in Xine. If you use XShm (compatible with almost any hardware, but slower) the image is kinda blocky indeed. But any player (not just Xine or mplayer) that uses the Xv mode has the same sharpness. I actually spent some time figuring out this issue and i'm pretty sure about what i said above.
Like i said, both players (Xine and mplayer) are pretty much the same, except that Xine handles DVDs a lot better (mplayer's implementation is only the bare minimum).
VLC is pretty cool, yeah. Especially if you wanna broadcast video on a LAN.
But for a media player, i found Xine to be better than both. It supports all the formats that mplayer supports, it also has a browser plugin, but it handles DVDs a lot better. In fact, the DVD menus and stuff like that works exactly as with a standalone DVD player.
They comment on those single-standard burners like they were state-of-the-art technology, without mentioning any of the two dozens of DVD burners out there which are able to create any DVD format. See this comparison. Much better.:-)
I am not sure whether or not it uses code from Wine. However, emulation is one thing, and understanding a different API is another. The former would happen if Xine would actually run in Wine, or would require Wine to run, somehow. That doesn't happen, hence it's not emulation. The latter means an application written for an API (or for an OS) can "understand" a different kind of libraries (such as a Linux application can understand Windows libraries). This is what happens with Xine using Windows DLLs. This is not emulation.
No, actually, the reason SVCD is higher quality is because the SVCD spec calls for higher resolutions than VCD, in exchange for each SVCD disc holding much less. Double the res for VCD, hence halve the run time, and you'll get quality similar to SVCD.
Nope. At the same resolution, at the same bitrate, MPEG2 will have a clearly better quality than MPEG1. The MPEG2 codec does more "clever" things to get more information into the same amount of bits. I actually tried that, and the result was obvious. I agree with you that the VCD standard specifies a ridiculously low bitrate and resolution, but in the same conditions MPEG2 (SVCD) still works better.
It's the same thing as with MP3 vs. MP2 vs. MP1. There are layers of processing that each codec builds upon the other. All these three codecs do the stuff MP1 does. Yet only MP2 and above do some "other" stuff. And MP3 alone does yet another, more "clever" processing. The result? Same bitrate, different quality, increasing from MP1 to MP3.
...some popular transcoding applications will start supporting it. One such as transcode (but any other popular transcoder will do). I mean, it's like the Linux kernel, if there is no heavy testing from lots of users (such as during the "development" phase), not a lot of bugs get squashed out. Yet, soon after the first stable (the first "dot-zero") release is out, the bug reports start pouring in. The same mechanism would probably help the Vorbis codec.
Nitpicker's P.S.: "transcoder" is the correct term for what's usually called "encoder". You're not just encoding when converting from, say, DVD to DivX, but you're actually trans-coding from one video format to another (decoding one format, encoding the other). That's what "trans-" means: "from one to another".
The only use it has is so 1337-k1dz can make (S)VCDs.
Nope, MPEG1 is only for VCD. SVCD uses MPEG2, which has a better quality. That's why VCD is so crappy, and SVCD is actually watchable. MPEG2 is also used by DVD, but at a much higher bitrate.
Just install Xine. Download and install the Windows DLLs. Done. Now you can play QuickTime files, and even QuickTime webcasts (not to mention Windows Media, because those DLLs contain the required codecs). Heck, if you install RealPlayer9 for *NIX, you can also play Real Media in Xine. If you install the gxine interface, not xine-ui (but you can install as many interfaces at the same time as you like) you even get a Mozilla plugin to play all those formats in your browser.;-) For the lazy, Red Hat RPM packages are here: freshrpms.net. No emulation (Wine or otherwise) required.
Slashdot Mirror
They only discontinue the usage of the "Red Hat" label on the free distro. Otherwise things remain the same.
That's typical slashdot bullshit.
:-)
What really happens is this:
Red Hat Inc. will cease to use the "Red Hat" label on its free distribution (previously known as "Red Hat Linux"), and continue using it exclusively on its paid-for distribution (a.k.a. RHEL - "Red Hat Enterprise Linux"). "Red Hat Linux" will become "Fedora Linux", and RHEL will continue to be the paid-for distribution.
Neither of these distributions will change in its inner core and/or "philosophy", with one exception: Red Hat will loose its grip a little
bit on Fedora (previously known as "Red Hat Linux"), which will become more open. Think of it as a combination between the old Red Hat Linux, and a non-corporate free Unix distribution such as Debian or FreeBSD.
Otherwise, the core of the development effort on Fedora will continue to be provided by Red Hat - hence the term "Fedora Core" used for the releases.
Essentially, Red Hat expects to continue as before with the development of the distribution, it's just that they opened the doors for contributions from outside related to packages of a secondary importance.
In fact, future versions of the paid-for RHEL will actually be older branches of Fedora Linux, plus proprietary additions by Red Hat Inc.
The older RH Linux versions (6.x, 7.x, 8) will become unsupported by Red Hat on Dec 31 2003, while RHL 9 will continue to be supported until Apr 30 2004. "Unsupported" meaning that Red Hat will not provide updates anymore. That's normal, and in fact it was amazing they continued to support 6.x for so long.
Fedora Linux will get a mixed support model: Red Hat will support Fedora releases for limited amounts of time (shorter than the
lifetime of the 6.x releases anyway!), together with support from the community built around the Fedora Project (a la Debian); once the
"official" Red Hat support for a certain Fedora version disappears, its the community support that will continue to provide updates for it.
My estimate is that the support provided by the community will actually last for a lot longer than the "official" support - see the case of the non-corporate Unix distributions such as Debian, FreeBSD, etc. which are supported for long periods of time.
Obviously, Red Hat is trying to draw as much attention as they can to their RHEL product, which is where their money come from. But i feel that, during this whole change, their "market droids" did a poor job of explaining what's really going on.
Hence the rumors that "Red Hat Linux goes away, everyone must buy RHEL or migrate to something else" etc. Oh wait, but then they did a _good_ job!
Fedora Core 1 (or "the distribution formerly known as Red Hat Linux 10") is scheduled for release this week.
Yes. It's called Chain Reaction.
It has several deinterlace algorithms, unsharp, denoise, resize, some other filters borrowed from TVtime (that's another very cool media application), etc.
a problem specifically with Xine's, and it's independent of skin. Buttons mysteriously stop working
I hope you're not insinuating that mplayer is faultless. It regularly has issues with full-screen mode, on several different Linux distributions. It loses A/V sync when playing DVDs more easily than any other popular DVD player (Xine, Ogle). etc.
I'm not saying that Xine is faultless either. But AFAICT, there's no clear "winner" in the crashing contest.
I also have a problem with the fact that Xine's volume button is independent of the mixer device. MPlayer uses the mixer directly, so if my wife watches a movie with MPlayer, and turns the volume down so it doesn't wake up the baby, then I have to open aumix (or another mixer) to restore the volume for Xine to play the sound audibly.
You probably never saw the "restore volum level at startup" option in xine. But since you said you never read the docs, it's not surprising.
my comment wasn't uninformed. I was trying to provide what I had experienced to another poster
I can see that, but you didn't present the information as personal experience (in that case it would have been ok), but as objective truths (which it wasn't). Hence my (arguably rough) tone.
Xine takes about 5 seconds to start up when you click on a movie file. MPlayer starts up in less than 1 second
I do agree with you that Xine takes a bit longer to start than mplayer. But in my experience the ratio is more like 3/2 not 5/1. Either you're exagerating, or something on your system is very different than on mine.
If it weren't for the tone of your post, I'd probably be more inclined to--as you say--read the docs for Xine, but I must say that you have completely failed to convince me I should bother
Not a big loss, from what i can see.
I've never even seen docs for Xine
You probably keep your eyes tightly shut, or read very selectively, otherwise i can't explain how you can miss the big honking Documentation link on their webpage.
So much for objective comments...
I almost exclusively use the text-only mplayer.
That is, when i do use it, because usually it's Xine which plays my media files.
That is a known issue. SuSE ships a broken Xine package. I've seen a lot of reports on that.
Red Hat also shipped a broken version a while ago.
Don't use the version shipped by SuSE. Go to the website and download the latest release. It works without problems.
Mplayer is not a particularly great choice for non-techies
Well, as long as you install the GUI, it should be quite usable by non-techies as well.
mplayer [...] is faster than anything else in existence
Actually, if you look at objective reports, you'll see that reality is a bit different. Quite a few people (non-biased observers) report that mplayer is by no means the fastest player available. E.G. on my system (AthlonXP/1800, GeForce2) actually it's Xine which has the lowest CPU usage almost any time.
Also, the "ours is the fastest player ever" is the most useless bit of the mplayer propaganda. If your CPU usage is below 5% no matter what's the player, who cares what's the "fastest" player. In my case, mplayer has a slightly higher CPU usage (and i did follow the build instructions to the letter) but that doesn't prevent me from using it every now and then (but in most cases i use Xine, especially when it comes to DVDs, since it has a far better DVD support - it can handle DVD menus properly).
mplayer [...] has support for just about every interface and codec under the sun
We mustn't forget that Xine plays all those formats as well. It's only a matter of installing the right codecs (Win32, Real, etc.).
The browser plugin included in the gxine GUI is trivial to install, just copy the right file into the Mozilla plugins directory (or your browser's plugins directory if you're not using Mozilla). No issues whatsoever, neither on my system, nor reported by other users on the mailinglist.
xine-0.9.13 (the last version in the previous "stable" series) indeed had some stability issues.
But you may try the latest pre-1.0 release, it seems to be rock stable. Also, if you install the Win32 codecs and Real, it plays all the formats supported by mplayer. Not to mention that DVD support is more evolved in Xine (handles DVD menus, etc.)
Indeed, i noticed the same thing. On my system (AthlonXP/1800, GeForce2, Red Hat 9) i constantly get lower CPU usage from Xine than from mplayer, even though the mplayer documentation is so proud about their supposed "lowest" CPU usage among all players. It's actually funny...
advantage I have with Mplayer is actually it's keyboard interface
You can control xine-ui with keyboard shortcuts as well. Moreover, there is a text-mode interface that you can use if you don't like the GUIs.
Read the docs before making uninformed comments.
MPlayer also has the ability to specify video and sound drivers on the command line. Xine may have it
Xine does have it. It's the -V and -A switches. Please read the docs.
Xine is GUI oriented
No. Xine is a library, not a player. Whatever interface you build on top of it, it's your decision, Xine doesn't care. Indeed, the existing interfaces seem to generally be oriented towards GUI, but there is at least one text-mode interface.
The biggest plus to using mplayer [...] comes when you associate it with the file extensions
That's ridiculous. You can associate extensions with any player, and the results are similar.
it doesn't seem to support all the same formats that mplayer does [...] Xine doesn't play .asf files
If you install the Win32 codecs, Xine will happily play all those formats you mention.
I've a few mpg's that mysteriously don't play on xine
I've a few mpg's that not misteriously don't play but on one of the players that i use (xine, VLC, mplayer...) and on none of the other. The "mplayer plays all files that other players won't play" myth is just that: a myth. You will always find files that are not playable on all players (or even worse, are playable on only one player).
mplayer renders much more sharply and clearly than xine
You are probably not using the Xv mode in Xine. If you use XShm (compatible with almost any hardware, but slower) the image is kinda blocky indeed. But any player (not just Xine or mplayer) that uses the Xv mode has the same sharpness. I actually spent some time figuring out this issue and i'm pretty sure about what i said above.
Like i said, both players (Xine and mplayer) are pretty much the same, except that Xine handles DVDs a lot better (mplayer's implementation is only the bare minimum).
VLC is pretty cool, yeah. Especially if you wanna broadcast video on a LAN.
But for a media player, i found Xine to be better than both. It supports all the formats that mplayer supports, it also has a browser plugin, but it handles DVDs a lot better. In fact, the DVD menus and stuff like that works exactly as with a standalone DVD player.
Dude, reconsider. That book is awesome. Think of it as "William Gibson meets true literary skills". :-)
This is just a kindergarten-level retelling of the whole book. There is nothing that defines a review in this "article".
3. ...profit! :-)
Now seriously:
3. Google has thousands of servers (or tens of thousands) to spread the load upon. That doesn't sound like a 20k project to me.
They comment on those single-standard burners like they were state-of-the-art technology, without mentioning any of the two dozens of DVD burners out there which are able to create any DVD format. See this comparison. Much better. :-)
The Sony DRU 500 and 510 can burn any format, so there's no need to worry about which format will be "the" standard.
They also have a store in Silicon Valley, in downtown Palo Alto. Great food store. :-)
It's not impossible that microwave owens of the future will refuse to work if they detect an RFID tag inside.
I am not sure whether or not it uses code from Wine. However, emulation is one thing, and understanding a different API is another.
The former would happen if Xine would actually run in Wine, or would require Wine to run, somehow. That doesn't happen, hence it's not emulation.
The latter means an application written for an API (or for an OS) can "understand" a different kind of libraries (such as a Linux application can understand Windows libraries). This is what happens with Xine using Windows DLLs. This is not emulation.
No, actually, the reason SVCD is higher quality is because the SVCD spec calls for higher resolutions than VCD, in exchange for each SVCD disc holding much less. Double the res for VCD, hence halve the run time, and you'll get quality similar to SVCD.
Nope. At the same resolution, at the same bitrate, MPEG2 will have a clearly better quality than MPEG1. The MPEG2 codec does more "clever" things to get more information into the same amount of bits.
I actually tried that, and the result was obvious.
I agree with you that the VCD standard specifies a ridiculously low bitrate and resolution, but in the same conditions MPEG2 (SVCD) still works better.
It's the same thing as with MP3 vs. MP2 vs. MP1. There are layers of processing that each codec builds upon the other. All these three codecs do the stuff MP1 does. Yet only MP2 and above do some "other" stuff. And MP3 alone does yet another, more "clever" processing. The result? Same bitrate, different quality, increasing from MP1 to MP3.
...some popular transcoding applications will start supporting it. One such as transcode (but any other popular transcoder will do).
I mean, it's like the Linux kernel, if there is no heavy testing from lots of users (such as during the "development" phase), not a lot of bugs get squashed out. Yet, soon after the first stable (the first "dot-zero") release is out, the bug reports start pouring in.
The same mechanism would probably help the Vorbis codec.
Nitpicker's P.S.: "transcoder" is the correct term for what's usually called "encoder". You're not just encoding when converting from, say, DVD to DivX, but you're actually trans-coding from one video format to another (decoding one format, encoding the other). That's what "trans-" means: "from one to another".
The only use it has is so 1337-k1dz can make (S)VCDs.
Nope, MPEG1 is only for VCD.
SVCD uses MPEG2, which has a better quality. That's why VCD is so crappy, and SVCD is actually watchable.
MPEG2 is also used by DVD, but at a much higher bitrate.
Just install Xine. Download and install the Windows DLLs. Done. Now you can play QuickTime files, and even QuickTime webcasts (not to mention Windows Media, because those DLLs contain the required codecs). Heck, if you install RealPlayer9 for *NIX, you can also play Real Media in Xine. ;-)
If you install the gxine interface, not xine-ui (but you can install as many interfaces at the same time as you like) you even get a Mozilla plugin to play all those formats in your browser.
For the lazy, Red Hat RPM packages are here: freshrpms.net.
No emulation (Wine or otherwise) required.