The linux fb driver has some acceleration for a few chipsets. I think the real benefit of using the fb over X, is that X uses a great deal of memory. The reason KDE crawls on a 486-100 with 16 MB of ram isn't because the video card is slow, it's because KDE (like GNOME) is a memory pig.
So they seem to say the problem is not that the initial ISN isn't created
randomly, it's that the subsequent numbers aren't incremeted randomly
(wouldn't that be hard to do?) but are rather incremented by the number
of bytes transmitted.
The ISN is the Initial Sequence Number. To say initial ISN is redundant; to talk about subsequent ISNs is wrong, as there are no such things. The bit you quote most definitely is saying that the ISN isn't getting chosen randomly.
Incrementing the sequence number randomly between packets is impossible. The purpose of the sequence number is to allow one machine to know if it failed to receive any packets. If one machine gets packets 1, 2, 3, 4, 6, and 7, it knows that packet 5 got lost. If the sequence numbers were random, how could you know if one was missing?
For each sequential packet, a new ISN is generated
While your post was very informative, this part isn't quite correct. The ISN is the Initial sequence number. The server generates it when it sends back the syn/ack packet to the client. The sequence number of subsequent packets is the ISN + the number of bytes transmitted so far.
So if the syn/ack packet had the pseudo-random sequence number 1042, and the next packet from the server contained the data "HELLO", its sequence number would be 1047.
It's worth pointing out that there are two seperate sequence numbers, the one generated by the server, and the one generated by the client. The client ISN is sent to the server in the SYN packet. It isn't a problem for spoofing, because the spoofer is the one generating it, so obviously they know what it is.
The ISN isn't created by two computers, just one. So the information used to create it doesn't go over the network. If you had a real random number generator, then guessing the ISN would be next to impossible without intercepting the traffic en-route to the real destination. But lacking that without special hardware, you have to settle for pseudorandom numbers. Some pseudorandom number generators have weaknesses that can be exploited.
Did you know it's rude to use a cell phone while being mugged? Muggers are on a busy schedule, they don't have time to sit around while you yak away. I bet if you tried to use your cell while being mugged, the mugger would be so offended they would just TAKE YOUR DAMN PHONE!
I don't have a cell phone, and I'm afraid to go outside! What if I have a heart attack, or get mugged, or there is a 6.8 earthquake? Oh wait, no ones cell phone worked after the earthquake.. I wonder how we survived in the dark ages before cell phones? I'll have to ask my parents if they still have their smoke-signal blanket, from the primitive cell-less days of 1980s.
I remember using warez FTP sites way back when, 1994 or earlier, and this was common practice. You can't have a secondary password on a anon-FTP site, so you make a directory with a name like dot-space-^h-tab-space-space-space-^m that is secret, then you only tell the person who you want to access the site the name of the secret directory.
I also seem to remember that PGP was distributed this way in the early years. You had to send an email to a bot at MIT, and they would tell you the name of some screwy FTP directory on their server to get it from. If you tried again a week later, it would be gone.
I even make a system like this myself in 1995. Someone would fill out a web form (forms were new!) and an image would be generated for them to download. It would get stuck on the FTP site, as img12345.jpg or something, for them to download. Then it would get deleted after a while. The ftp path was provided as a URL, the URL identified the document, the server stored it temporarily, and logged the transfer. Seems to satisify all their claims.
Your DSL just sucks. With Speakeasy/Covad SDSL I get much better latency:
64 bytes from 206.253.x.x: icmp_seq=0 ttl=254 time=18.3 ms
64 bytes from 206.253.x.x: icmp_seq=1 ttl=254 time=16.2 ms
64 bytes from 206.253.x.x: icmp_seq=2 ttl=254 time=17.1 ms
64 bytes from 206.253.x.x: icmp_seq=3 ttl=254 time=16.1 ms
I've had this DSL line for over two years now, and my latency has stayed the same the entire time. You'll find a lot of people who thought their cable modems were great, but six months later changed their tune as thier local loop gets overloaded.
Depends on the DVD of course. DVDs made from things that came out on film are at 24fps. A NTSC DVD player converts this to 60 fields/sec using a process called a 4/3 pulldown. A PAL DVD player would convert it to 25 fps by just playing it faster.
If your DVD is from something that wasn't shot on film, like porn, then it would be 30fps.
Unfortunately, static linking isn't the answer. If you statically link an
app with glibc2.1, and then try to run it on a system that only has glibc2.0
or libc5, it probably won't work.
If you don't believe me, try downloading my Netrek client Paradise-2000 and
running the static glibc2.1 binary on a system with an older libc. Hostname
lookups won't work. The problem is that glibc2.1's resolve code tries to
access the dynamic library/lib/libnss_files.so.2, which doesn't exist on
pre-glibc2.1 systems. Since this library isn't dynamically linked, it doesn't
show up in the output of ldd, you can't statically link it when you compile
the program. Rather, the/lib/libnss_* libraries are loaded with dlopen().
So I'm forced to compile three separate static versions of my program, and
that doesn't even count glibc2.2 which I'm not using yet.
Another problem with static linking is one of efficiency. A statically linked
program has it's own copy of the libc (huge) in the executable. Besides
making the executable huge if you want to download it, it uses a ton of extra
memory. Instead of using the copy of libc that is probably already in memory
and shared with the processes you have running, the statically linked program
needs to load its own private copy of the libc code into memory, which won't
get shared with any other program. The result is the memory needs of your system would double or more if every binary you had was statically linked.
These already exist. They're called busses. Not only do you not need to drive them or do any maintenance yourself, it's actually much cheaper than a car. They're also much more space and fuel efficient than single occupancy vehicles.
Unfortunately, most people have been programmed by big business to think that it is necessary to use their very own vehicle. Preferably one as large fuel inefficient as possible.
~
I called a bunch of Office Depots in the Seattle area, but none of them seemed to know anything about the Garmin GPS III+ being on sale. Maybe it was just your store that had some?
Last time I checked there were 8 bits in a byte, not 1000. That would be 100,000 visitors, if he is in fact referring to bits, which is still quite a few some guy's worthless homepage.
The bit quoted in the wired article is:
Section III.A.3 reads: "In the event you consume more than 30kbp/s of sustained peak traffic within any 24 hour period of time... a fee of $1 dollar per 1kbp/s will be billed to your account.
It's not clear to me if that's 30 kiloBITS or kiloBTYES. I'm also not clear on what "sustained peak" is supposed to mean, it sounds like an oxymoron to me. If someone downloads a 1k web page in 1ms, that's a transfer rate of 8000kb/sec. So would they have to pay $8000 because someone on a T3 downloaded a 1k web page once? A normal usage fee for hosting is based on total data transfered, i.e. megabytes, not "sustained peak" rate, kilobits per second.
It's not a 33% across the board raise, it's more like 2% to 33%. If you're a GS-5 (that's pretty low level, like 20k a year or so) in San Francisco, you get the 33%.
When I started my current job in Seattle three years ago while still in college, I was a Computer Specialist, grade 7. These guys are getting something like 20% raises. Now I'm a Computer Scientist, grade 11 and I'll get something like 4%. If I were a Computer Engineer, which would require nothing more than having a degree in comp E instead of comp sci, I'd have been getting the extra pay all along.
I've been archiving them too, with a DC10+ for hardware MJPEG capture, then convert to MPEG1 for burning to CD.
But so far season 2 isn't widescreen, its the same thing as before, but the top and bottom has been cropped off. It really looks like crap when you have close-ups of someone talking and their mouth is off the bottom of the screen!
Season 1 wasn't all widescreen either. All the shots with CGI or some kind of EFX aren't widescreen, but are cropped or squished from the plain old 4:3 version. I've got a few comparisons on my web page, digital recording makes screen shots easy: http://www.speakeasy.org/~xyzzy/b5/
They went through something like 250 pounds of salt dug up from the construction of a nuclear waste dump in new mexico for salt crystals that were "good". Then they sterilized the crystals, extracted some material from inside them, and cultivated it. That means stuck it in a petri disk and waited to see what grew.
So to say they revived _a_ 250-million-year-old bacteria, isn't really correct. It's more like they have a colony of bacteria, and they are pretty sure that these bacteria grew from a spore inside a 250 million year old salt crystal.
It's not like they found a bacteria inside the crystal, and gave it CPR, and this tube with a re-animated bacterial swimming around. That's part of what the criticism of their work is about, how can they be sure the bacteria came from a spore in the salt crystal and not someone's sneeze?
Voltron would lose. Voltron always fights first as the lions and gets their asses kicked, before they decide to form voltron. They wouldn't have time in battle bots because the rounds are 3 minutes long, and the stock voltron forming footage, "Form legs and arms! Form feet and hands! Form...", takes like 5 minutes.
If you don't want to drop the cash on a TiVo, you can do the same thing with an $80 DC10+ capture card and this Linux driver.
An epsisode of battle bots is 30 minutes long, and contains 3 battles. Each battle lasts at most 3 minutes, and usually one battle will be over in 1 minute or less. So you've got about 7 minutes of robot fighting and 23 minutes of commercials and, well, mindless drivel.
If they actually talked to the designers about the bots, how they are built, what kind of batteries they use, running time, what they use for armor, cost, etc. it would be interesting. But instead they say things like, "the one bot, like, hit the other one, huhuhuhuh, bang!, huhuhuh. Ram, ram, ram!! yeah! ram him with the rod! huhuhuh! The bot with the rod is totally mondo super cool, dude!"
If you pay attention you can spot clever things they designers have done, like little hooks on the side of the bot to stop wedges from getting under, or fenders that flip up to prevent the bot from getting tipped. It would be more intesting the the drivel the have now if they let the designers give a "tour" of the bot and point these things out.
I remember reading an interesting post about the titanium industry in rec.bicycles.tech a while back. So I went and found it on dejanews so I could whore for karma. Actually, I just thought other people might find it interesting too.
As one of those responsible for the titanium rush, perhaps I can shed some light
on where the titanium used in bikes comes from.
Most of the titanium used in bikes comes from Australia. Yup, the deserts of
western Australia are the source for most of the titanium ore used in the world
today. Titanium ore is an abundant resource (titanium is the fifth most abundant
metallic element on our planet), and white sand is the best place to find it.
Most of this material never is never processed into metal. Over 90% is refined into
titanium dioxide, a common white pigment used in paint.
The most common destination for the sand used in making metallic titanium is
China. The Chinese produce a very high quality titanium sponge that is used
worldwide to produce primary mill products all over the world. The United States,
France, Russia, and Ukraine all produce sponge as well. Most US producers of
primary mill products use a significant amount of Chinese produced titanium
sponge.
In most cases, virgin material is mixed 1:4 with scrap material making titanium
one of the most recycled metals. This is where the Russian or Ukraine material
comes in. Most scrap from the former Soviet states is contaminated, and cannot be
used to produce ingot for tube production. Material with high levels of chemical
contamination can be used for low quality castings, and finds its' way into golf club
head, valve bodies, etc.
About the only titanium tube that you will find that contains significant amounts
of Russian material is tube from Russia. There is not a great economic advantage in
using poor quality scrap from Russia, when high grade domestic scrap is available in
the United States.
Litespeed uses material from Ancotech and Haynes International. The sponge used
to produce the raw material for these tubes is from either China or Henderson
(Nevada) depending on the price. Orement/Wah Chang or Timet produce 100% of
all the starting billets used by the big three companies in the United States
(Ancotech, Haynes International, and Sandvik Special Metals).
Oremet (Albany Oregon) has broken and recycled an entire pressure hull from an
Alpha attack sub. None of the material was used to produce ingot for tube
production, but this may be a source for much of the Urban Mythology surrounding
bikes made from radioactive Russian titanium. Most of the recovered material
became golf driver heads.
This a single machine, so it would be more correct to compare to the section 1.3 machine:
1.3 The highest multiple-CPU Linux boot sequence BogoMips value
Richard Langis, rlangis@primux.geekfest.net
8x Pentium III (Xeon) at 500 MHz, SMP
3996.06 BogoMips
And 46170.9 soundly trounces 3996.06.
The section 1.4 machine:
1.4 The highest non-Linux BogoMips value
zumbusch@iam.uni-bonn.de
Parnass2, 144 Pentium II CPUs, in SMP2 configurations, at 400MHz
Myrinet Multiprocessing over Linux/SMP
57684.96 BogoMips
They say "non-Linux", but it is running Linux. It's also adding up the bogomips from a bunch of seperate computers, which isn't really fair. I could go add up all the bogomips from the machines on the LAN in the building here, and get an even bigger number.
It seems all the these certifications refer to the design of the system, and don't address implementation aspects.
Suppose your C2 certified NT machine has a bug or backdoor that no one knew about, that let you overwrite system memory with anything you want if you push a magic keyboard combination. Well, all that access control list and whatnot doesn't mean squat. Up,down,left,right,A,B and poof, you can do anything you want.
Of course, how can you tell an implementation doesn't have bugs or backdoors when you don't have the source?
They freed up their patent two weeks before it expired, not a lot of guts in that!
At least they didn't try to extend the patent by tricking the patent office. For instance, "c = me mod n" is the formula for RSA. So they patented that formula back in 1983, then in 1985 they could have patented the formula "me = c mod n". Mathematically the same formula of course, but that's ok. The patent office will let you patent a formula or algorithm that has already been patented, as long as patent is worded differently enough that the monkey who rubber-stamps patents doesn't notice. The comp.compression FAQ has a section on patents, which has several patents for identical compression algorithms that the patent office rubber-stamp monkey didn't notice.
They could just make up a new patent every year. Like "Using RSA to exchange DES keys", then "Using RSA to exchange IDEA keys", "Using RSA to exchange keys over computers connected by telecommunication lines", "Using RSA to exchange keys over the internet", "Using RSA to exchange keys between web browsers". They could probably keep this up for as long as they wanted.
The robocup sounds interesting, but it's hard to tell when I've never actually seen it. Is there some way to watch the robots play other than quicktime movies that can't be viewed on Linux?
Slashdot Mirror
The linux fb driver has some acceleration for a few chipsets. I think the real benefit of using the fb over X, is that X uses a great deal of memory. The reason KDE crawls on a 486-100 with 16 MB of ram isn't because the video card is slow, it's because KDE (like GNOME) is a memory pig.
Incrementing the sequence number randomly between packets is impossible. The purpose of the sequence number is to allow one machine to know if it failed to receive any packets. If one machine gets packets 1, 2, 3, 4, 6, and 7, it knows that packet 5 got lost. If the sequence numbers were random, how could you know if one was missing?
While your post was very informative, this part isn't quite correct. The ISN is the Initial sequence number. The server generates it when it sends back the syn/ack packet to the client. The sequence number of subsequent packets is the ISN + the number of bytes transmitted so far.
So if the syn/ack packet had the pseudo-random sequence number 1042, and the next packet from the server contained the data "HELLO", its sequence number would be 1047.
It's worth pointing out that there are two seperate sequence numbers, the one generated by the server, and the one generated by the client. The client ISN is sent to the server in the SYN packet. It isn't a problem for spoofing, because the spoofer is the one generating it, so obviously they know what it is.
The ISN isn't created by two computers, just one. So the information used to create it doesn't go over the network. If you had a real random number generator, then guessing the ISN would be next to impossible without intercepting the traffic en-route to the real destination. But lacking that without special hardware, you have to settle for pseudorandom numbers. Some pseudorandom number generators have weaknesses that can be exploited.
Did you know it's rude to use a cell phone while being mugged? Muggers are on a busy schedule, they don't have time to sit around while you yak away. I bet if you tried to use your cell while being mugged, the mugger would be so offended they would just TAKE YOUR DAMN PHONE!
I don't have a cell phone, and I'm afraid to go outside! What if I have a heart attack, or get mugged, or there is a 6.8 earthquake? Oh wait, no ones cell phone worked after the earthquake.. I wonder how we survived in the dark ages before cell phones? I'll have to ask my parents if they still have their smoke-signal blanket, from the primitive cell-less days of 1980s.
I remember using warez FTP sites way back when, 1994 or earlier, and this was common practice. You can't have a secondary password on a anon-FTP site, so you make a directory with a name like dot-space-^h-tab-space-space-space-^m that is secret, then you only tell the person who you want to access the site the name of the secret directory.
I also seem to remember that PGP was distributed this way in the early years. You had to send an email to a bot at MIT, and they would tell you the name of some screwy FTP directory on their server to get it from. If you tried again a week later, it would be gone.
I even make a system like this myself in 1995. Someone would fill out a web form (forms were new!) and an image would be generated for them to download. It would get stuck on the FTP site, as img12345.jpg or something, for them to download. Then it would get deleted after a while. The ftp path was provided as a URL, the URL identified the document, the server stored it temporarily, and logged the transfer. Seems to satisify all their claims.
Your DSL just sucks. With Speakeasy/Covad SDSL I get much better latency:
64 bytes from 206.253.x.x: icmp_seq=0 ttl=254 time=18.3 ms
64 bytes from 206.253.x.x: icmp_seq=1 ttl=254 time=16.2 ms
64 bytes from 206.253.x.x: icmp_seq=2 ttl=254 time=17.1 ms
64 bytes from 206.253.x.x: icmp_seq=3 ttl=254 time=16.1 ms
I've had this DSL line for over two years now, and my latency has stayed the same the entire time. You'll find a lot of people who thought their cable modems were great, but six months later changed their tune as thier local loop gets overloaded.
Tell me about it. I tie my pens down now with a long piece of string.
Depends on the DVD of course. DVDs made from things that came out on film are at 24fps. A NTSC DVD player converts this to 60 fields/sec using a process called a 4/3 pulldown. A PAL DVD player would convert it to 25 fps by just playing it faster.
If your DVD is from something that wasn't shot on film, like porn, then it would be 30fps.
If you don't believe me, try downloading my Netrek client Paradise-2000 and running the static glibc2.1 binary on a system with an older libc. Hostname lookups won't work. The problem is that glibc2.1's resolve code tries to access the dynamic library /lib/libnss_files.so.2, which doesn't exist on
pre-glibc2.1 systems. Since this library isn't dynamically linked, it doesn't
show up in the output of ldd, you can't statically link it when you compile
the program. Rather, the /lib/libnss_* libraries are loaded with dlopen().
So I'm forced to compile three separate static versions of my program, and that doesn't even count glibc2.2 which I'm not using yet.
Another problem with static linking is one of efficiency. A statically linked program has it's own copy of the libc (huge) in the executable. Besides making the executable huge if you want to download it, it uses a ton of extra memory. Instead of using the copy of libc that is probably already in memory and shared with the processes you have running, the statically linked program needs to load its own private copy of the libc code into memory, which won't get shared with any other program. The result is the memory needs of your system would double or more if every binary you had was statically linked.
mwm, light weight? Before the new generation of bloated eye-candy WMs, mwm was about as big as they came.
fvwm1 was designed to have less memory usage than twm, though fvwm2 is probably larger.
I still use fvwm2, because you can configure it so much more than other WMs.
These already exist. They're called busses. Not only do you not need to drive them or do any maintenance yourself, it's actually much cheaper than a car. They're also much more space and fuel efficient than single occupancy vehicles.
Unfortunately, most people have been programmed by big business to think that it is necessary to use their very own vehicle. Preferably one as large fuel inefficient as possible.
~
I called a bunch of Office Depots in the Seattle area, but none of them seemed to know anything about the Garmin GPS III+ being on sale. Maybe it was just your store that had some?
The bit quoted in the wired article is:
It's not clear to me if that's 30 kiloBITS or kiloBTYES. I'm also not clear on what "sustained peak" is supposed to mean, it sounds like an oxymoron to me. If someone downloads a 1k web page in 1ms, that's a transfer rate of 8000kb/sec. So would they have to pay $8000 because someone on a T3 downloaded a 1k web page once? A normal usage fee for hosting is based on total data transfered, i.e. megabytes, not "sustained peak" rate, kilobits per second.It's not a 33% across the board raise, it's more like 2% to 33%. If you're a GS-5 (that's pretty low level, like 20k a year or so) in San Francisco, you get the 33%.
When I started my current job in Seattle three years ago while still in college, I was a Computer Specialist, grade 7. These guys are getting something like 20% raises. Now I'm a Computer Scientist, grade 11 and I'll get something like 4%. If I were a Computer Engineer, which would require nothing more than having a degree in comp E instead of comp sci, I'd have been getting the extra pay all along.
I've been archiving them too, with a DC10+ for hardware MJPEG capture, then convert to MPEG1 for burning to CD.
But so far season 2 isn't widescreen, its the same thing as before, but the top and bottom has been cropped off. It really looks like crap when you have close-ups of someone talking and their mouth is off the bottom of the screen!
Season 1 wasn't all widescreen either. All the shots with CGI or some kind of EFX aren't widescreen, but are cropped or squished from the plain old 4:3 version. I've got a few comparisons on my web page, digital recording makes screen shots easy: http://www.speakeasy.org/~xyzzy/b5/
They went through something like 250 pounds of salt dug up from the construction of a nuclear waste dump in new mexico for salt crystals that were "good". Then they sterilized the crystals, extracted some material from inside them, and cultivated it. That means stuck it in a petri disk and waited to see what grew.
So to say they revived _a_ 250-million-year-old bacteria, isn't really correct. It's more like they have a colony of bacteria, and they are pretty sure that these bacteria grew from a spore inside a 250 million year old salt crystal.
It's not like they found a bacteria inside the crystal, and gave it CPR, and this tube with a re-animated bacterial swimming around. That's part of what the criticism of their work is about, how can they be sure the bacteria came from a spore in the salt crystal and not someone's sneeze?
Voltron would lose. Voltron always fights first as the lions and gets their asses kicked, before they decide to form voltron. They wouldn't have time in battle bots because the rounds are 3 minutes long, and the stock voltron forming footage, "Form legs and arms! Form feet and hands! Form...", takes like 5 minutes.
An epsisode of battle bots is 30 minutes long, and contains 3 battles. Each battle lasts at most 3 minutes, and usually one battle will be over in 1 minute or less. So you've got about 7 minutes of robot fighting and 23 minutes of commercials and, well, mindless drivel.
If they actually talked to the designers about the bots, how they are built, what kind of batteries they use, running time, what they use for armor, cost, etc. it would be interesting. But instead they say things like, "the one bot, like, hit the other one, huhuhuhuh, bang!, huhuhuh. Ram, ram, ram!! yeah! ram him with the rod! huhuhuh! The bot with the rod is totally mondo super cool, dude!"
If you pay attention you can spot clever things they designers have done, like little hooks on the side of the bot to stop wedges from getting under, or fenders that flip up to prevent the bot from getting tipped. It would be more intesting the the drivel the have now if they let the designers give a "tour" of the bot and point these things out.
This a single machine, so it would be more correct to compare to the section 1.3 machine:
1.3 The highest multiple-CPU Linux boot sequence BogoMips value
Richard Langis, rlangis@primux.geekfest.net
8x Pentium III (Xeon) at 500 MHz, SMP
3996.06 BogoMips
And 46170.9 soundly trounces 3996.06.
The section 1.4 machine:
1.4 The highest non-Linux BogoMips value
zumbusch@iam.uni-bonn.de
Parnass2, 144 Pentium II CPUs, in SMP2 configurations, at 400MHz
Myrinet Multiprocessing over Linux/SMP
57684.96 BogoMips
They say "non-Linux", but it is running Linux. It's also adding up the bogomips from a bunch of seperate computers, which isn't really fair. I could go add up all the bogomips from the machines on the LAN in the building here, and get an even bigger number.
But check out that floppy, it's a 2.88MB! Even the floppy drive is better than what I've got in the beowulf cluster at work. I feel so inferior.
I bet my keyboard is better than theirs, at least I have that.
It seems all the these certifications refer to the design of the system, and don't address implementation aspects.
Suppose your C2 certified NT machine has a bug or backdoor that no one knew about, that let you overwrite system memory with anything you want if you push a magic keyboard combination. Well, all that access control list and whatnot doesn't mean squat. Up,down,left,right,A,B and poof, you can do anything you want.
Of course, how can you tell an implementation doesn't have bugs or backdoors when you don't have the source?
At least they didn't try to extend the patent by tricking the patent office. For instance, "c = me mod n" is the formula for RSA. So they patented that formula back in 1983, then in 1985 they could have patented the formula "me = c mod n". Mathematically the same formula of course, but that's ok. The patent office will let you patent a formula or algorithm that has already been patented, as long as patent is worded differently enough that the monkey who rubber-stamps patents doesn't notice. The comp.compression FAQ has a section on patents, which has several patents for identical compression algorithms that the patent office rubber-stamp monkey didn't notice.
They could just make up a new patent every year. Like "Using RSA to exchange DES keys", then "Using RSA to exchange IDEA keys", "Using RSA to exchange keys over computers connected by telecommunication lines", "Using RSA to exchange keys over the internet", "Using RSA to exchange keys between web browsers". They could probably keep this up for as long as they wanted.
The robocup sounds interesting, but it's hard to tell when I've never actually seen it. Is there some way to watch the robots play other than quicktime movies that can't be viewed on Linux?