Sure they do. I am using this functionality on my MythTV box right now.
When MythTV wants to change channel on the cable box, it calls a user-definable external script. I use LIRC to emit the IR control codes to switch channels on my General Instruments cable box.
That's all well and good, but recall that the case is not about Microsoft being a monopoly, but abusing its monopolistic position.
When Microsoft abuses their dominant position (for instance, to prevent hardware vendors from preloading Linux on their machines), there is a problem that needs to be addressed.
The violation is (as I understand it) due to the fact that when they provide you with Linux, SCO imposes its own (more restrictive) license. This is something the GPL explicitly prohibits.
I think you're overstating things a bit here. The register.com "coming soon" page was a convenience, nothing more - the moment you set valid DNS server addresses, your domain information is updated.
This lawsuit was fairly frivolous if you ask me. It was covered on Slashdot a while back here.
This is nothing like the Verisign case - what they are doing is abusing a monopoly position, and in doing so, causing havoc with a number of internet-based pieces of software, most notably spam filters.
There are already several companies that run "affiliate programs", whereby they avoid the liabilities associated with spamming by paying any Joe Public willing to do the job to "advertise" for them (this generally means spamming). When someome complains, they say "Oh my! We don't endorse spamming! we'll cancel that affiliate's account immediately!". Of course it's pretty obvious that they do condome spam.
Now, what if your 'affiliates' are overseas, and outside the reach of this legislation? Already over half my spam comes to me courtesy of China.
It would be difficult to hold the company responsible, since they can just claim that their affiliates are running amok, and it's not their fault. You can't prosecute the affiliates because they're not in the USA. So. Back to square one.
No - the PS2 Linux kit is basically a keyboard, hard-drive and ethernet adapatr, plus a version of Linux on DVD. It runs on a standard PS2.
The official devkits (TOOLs) consist of a PC and a PS2 in the same box. The PC runs Linux, and handles code download/debugging between the PS2 and the developer's PC. The PS2 doesn't run Linux.
The Linux kit is cool to start developing on, provided you're not a novice - Sony provides 90% of the official PS2 docs, as well as a bunch of sample code. If you want to learn how to throw DMA chains at the vector units, it's a good start. Unfortunately, gdb is about as sophisticated a debugger as you're going to get. Also, there's no mechanism provided for debugging the vector units. Bear in mind we're talking about relatively low-level code here.
Another big problem is that since Linux is a virtual memory environment, your DMA chains have to be pre-processed by the kernel in order to translate all the virtual memory addresses to physical ones, which basically means your code will never be as fast as it would be on a TOOL, or a PS2 without Linux.
Oh yes - one other thing - the TOOLs have 128MB of RAM, the real PS2's only have 32MB.
Because Microsoft currently makes a significant loss on every console sold. They count on making up that loss through the sale of games. People converting XBoxes into Linux servers do not tend to buy XBox games.
As for raising the price - that will simply stop people buying them. If they become significantly more expensive it becomes cheaper to just buy a PC.
Actually, multicasting isn't a viable solution for streaming across the Internet in general.
It's great for streaming content on a single LAN (provided your switches are multicast aware), but since most internet-radio listeners are on physically separate networks, they would need to tunnel the multicast stream onto their LAN - which necessitates them receiving their own copy of the stream anyhow.
Our software uses P2P connections between listening peers to lower the bandwidth costs for the stream provider. We also do a metric assload of work to ensure that buffering time is kept to a minimum and if the parent peer disappears suddenly, redirection is as swift and unnoticeable as possible.
In real-world situations we are able to save 75-80% of bandwidth costs on 100Kbit streams.
Great... so you have a small embedded device with very limited CPU horsepower. What better way to grind it to a halt than to require it to compress a bitmap of the entire screen, and squirt the result over a TCP connection?
If you're configuring an embedded device remotely, then it makes much more sense to either:
(a) use a plain old web page served over HTTP
or
(b) serve up a Java applet with a custom dialog that then sends HTTP requests back to the device.
Both of these solutions are far more lightweight in terms of memory and bandwidth requirements. VNC is just overkill.
As far as I can see, the DMCA is unlikely to apply here since plain (non-DRM'd) ASF streams do not contain any form of copy protection.
If I remember correctly, though, Microsoft has a patent on the ASF format scheme itself. The granting of this patent in the first place was ridiculous - (thought sadly commonplace these days) - ASF is a very simple format for multiplexing video/audio/whatever over a single stream. There's nothing innovative about it.
Of course plenty of patents are issued these days for very unimaginative, uninnovative things - what makes MS's patent so unusual is that it's tantamount to patenting a file format - something that could effectively prevent otherwise legal reverse-engineering.
The author of Virtual Dub was forced to remove ASF compatibility after pressure from Microsoft regarding the patent.
Microsoft - boldly leading us back into the dark ages of incompatibility!
Depends on whether or not you view ASF stream protocols as containing copy-protection, which non-DRM'd streams certainly don't. If there's no copy-protection to "circumvent" then surely the DMCA doesn't apply?
The bigger problem for Real, I would imagine, is the (insane!) patents that Microsoft was able to obtain for the ASF protocol. Despite the fact that ASF is basically very simple, MS was able to obtain a patent, thus effectively preventing anyone from producing anything compatible with it unless they license the Windows Media Format SDK.
If there is no God, there is no Moral Authority. No reason to denounce the Holocaust. No reason to denounce the Crusades. No reason for Republicanism. I recommend a a little time in American History class.
DUDE...
If you believe that the only source of morals is some imaginary guy with a white beard that sits up in the clouds and gets pissed off when you masturbate, you are an idiot.
I don't need your god to tell me how I should behave toward other people.
Since RAM is limited to 256K(slow) + 32K(fast), it's unlikely you're going to fit a Linux distro that can do anything meaningful. Bear in mind that the ARM7 does not have a MMU, so you'd be limited to uCLinux or something of that ilk.
Yes. In fact, there's a port of an emulator which runs NES binaries
Descent is probably beyond the GBA's capabilities, since it uses arbitrarily-angled perspective-correct textured polygons, which are a fair bit harder to render on a low-end CPU (the GBA has a 16MHz ARM7 CPU). You should see some of the stuff that's going on. There are a number of fully textured 3D engines out there, one of which actually uses Descent levels as its examples! (I linked to another in my previous post which uses the quake level 1) A good example is the Raylight [raylight.it] engine, though there are probably a dozen that I've seen (and a few proprietary, one of which I'm about halfway done writing:) )
None of these engines do true perspective correct texturing. And yes, I'm fairly aware of the work that's going on out there - I am the author of FooN, and have also written a bunch of 3d engines for the GBA. My point was that, while DOOM/GBA is a more-or-less exact replica of the PC version, Descent/GBA is not going to look anywhere near as cool as the original.
Sorry - should have clarified - the ones I listed are all emulators for the GBA. Sorry, but not even remotely close. You didn't even get the popular ones. There's a pretty decent list here [zophar.net], at Zophar's Domain (a pretty good dev site)
Read. Comprehend. Post.
"The ones I listed are all emulators for the GBA". Not "These are all the emulators for the GBA". In other words, the emulators I listed are all emulators that run on the GBA, and emulate other machines.
Another thing - you mistakenly state that the GBA has a Z-buffer. WTF? As someone who claims to be developing a 3D engine for the GBA, you must be aware that the GBA most certainly doesn't have a Z buffer. It doesn't even have any polygon rendering hardware.
Sorry - should have clarified - the ones I listed are all emulators for the GBA. You can burn a flash cart containing 100's of old videogame classics, and play them on your GBA.
Descent is probably beyond the GBA's capabilities, since it uses arbitrarily-angled perspective-correct textured polygons, which are a fair bit harder to render on a low-end CPU (the GBA has a 16MHz ARM7 CPU).
I guess you could just flat-shade the whole thing, but it wouldn't look anywhere near as good.
On the contrary. Articles have been written regarding the viability of the XBox as a server. Since they're so cheap, you could (perhaps) install BSD/Linux and use them as a web farm.
Since MS is making a loss on each box sold (they expect to make up the difference in sales of games), this, if anything, would be a damaging blow to MS.
Can someone tell me if Overlapped IO under Win32 is also zero-copy? It seems like it could be - basically you pass buffers to the OS, and the OS lets you know when it's finished with them. This works for input and output.
The other nice thing about OIO is that you don't have to populate your FDSET every time you do a select - which means if you're writing a server app with thousands of simultaneous connections, it's a whole lot faster.
The viruses that have been widely propagated so far have all been fairly benign - they haven't done that much other than propagate. After all, a virus doesn't spread terribly well if it destroys its host.
Imagine what the impact would be, however, of a virus that spreads as effectively as Code Red, but formats the hard-drive after 48 hours? (Or perhaps after it's infected a certain number of machines?)
There were plenty of IIS machines that were infected for a good deal longer than 48 hours before their owners became aware of it. Hell - my boxes at home still receive hundreds of Code Red probes.
The flow of IIS vulnerabilities doesn't seem to be drying up - it may well only be a matter of time before someone writes something that's really malicious. Growing complacent because the computer press has cried wolf so many times is incredibly dangerous.
I don't read this as implying that the DMCA requires anything... just that a person is legally permitted to reverse engineer a protocol/format in order to acheive interoperability.
Knowing Microsoft, their next step will be to implement a completely new filesystem, encourage (force) everyone to upgrade, and protect it with encryption (if they claim that the encryption is for protection of a user's intellectual property, then perhaps the DMCA would have more teeth in this situation), and/or patents (somewhat akin to what they did with ASF).
Microsoft - boldly leading us back into the dark ages of incompatibility.
Slashdot Mirror
Program listings are readily available through XMLTV. MythTV (and I believe Freevo) are tightly integrated with XMLTV.
Sure they do. I am using this functionality on my MythTV box right now.
When MythTV wants to change channel on the cable box, it calls a user-definable external script. I use LIRC to emit the IR control codes to switch channels on my General Instruments cable box.
That's all well and good, but recall that the case is not about Microsoft being a monopoly, but abusing its monopolistic position.
When Microsoft abuses their dominant position (for instance, to prevent hardware vendors from preloading Linux on their machines), there is a problem that needs to be addressed.
The violation is (as I understand it) due to the fact that when they provide you with Linux, SCO imposes its own (more restrictive) license. This is something the GPL explicitly prohibits.
Unofficial GBA devkits have been around for years. The GBA doesn't have any crypto protection - it's trivial to make a bootable cart.
I think you're overstating things a bit here. The register.com "coming soon" page was a convenience, nothing more - the moment you set valid DNS server addresses, your domain information is updated.
This lawsuit was fairly frivolous if you ask me. It was covered on Slashdot a while back here.
This is nothing like the Verisign case - what they are doing is abusing a monopoly position, and in doing so, causing havoc with a number of internet-based pieces of software, most notably spam filters.
There are already several companies that run "affiliate programs", whereby they avoid the liabilities associated with spamming by paying any Joe Public willing to do the job to "advertise" for them (this generally means spamming). When someome complains, they say "Oh my! We don't endorse spamming! we'll cancel that affiliate's account immediately!". Of course it's pretty obvious that they do condome spam.
Now, what if your 'affiliates' are overseas, and outside the reach of this legislation? Already over half my spam comes to me courtesy of China.
It would be difficult to hold the company responsible, since they can just claim that their affiliates are running amok, and it's not their fault. You can't prosecute the affiliates because they're not in the USA. So. Back to square one.
No - the PS2 Linux kit is basically a keyboard, hard-drive and ethernet adapatr, plus a version of Linux on DVD. It runs on a standard PS2.
The official devkits (TOOLs) consist of a PC and a PS2 in the same box. The PC runs Linux, and handles code download/debugging between the PS2 and the developer's PC. The PS2 doesn't run Linux.
The Linux kit is cool to start developing on, provided you're not a novice - Sony provides 90% of the official PS2 docs, as well as a bunch of sample code. If you want to learn how to throw DMA chains at the vector units, it's a good start. Unfortunately, gdb is about as sophisticated a debugger as you're going to get. Also, there's no mechanism provided for debugging the vector units. Bear in mind we're talking about relatively low-level code here.
Another big problem is that since Linux is a virtual memory environment, your DMA chains have to be pre-processed by the kernel in order to translate all the virtual memory addresses to physical ones, which basically means your code will never be as fast as it would be on a TOOL, or a PS2 without Linux.
Oh yes - one other thing - the TOOLs have 128MB of RAM, the real PS2's only have 32MB.
Because Microsoft currently makes a significant loss on every console sold. They count on making up that loss through the sale of games. People converting XBoxes into Linux servers do not tend to buy XBox games.
As for raising the price - that will simply stop people buying them. If they become significantly more expensive it becomes cheaper to just buy a PC.
Actually, multicasting isn't a viable solution for streaming across the Internet in general.
It's great for streaming content on a single LAN (provided your switches are multicast aware), but since most internet-radio listeners are on physically separate networks, they would need to tunnel the multicast stream onto their LAN - which necessitates them receiving their own copy of the stream anyhow.
The company I'm working for right now does exactly this.
Our software uses P2P connections between listening peers to lower the bandwidth costs for the stream provider. We also do a metric assload of work to ensure that buffering time is kept to a minimum and if the parent peer disappears suddenly, redirection is as swift and unnoticeable as possible.
In real-world situations we are able to save 75-80% of bandwidth costs on 100Kbit streams.
err... and an HTTP server needs a screen because...?
Great... so you have a small embedded device with very limited CPU horsepower. What better way to grind it to a halt than to require it to compress a bitmap of the entire screen, and squirt the result over a TCP connection?
If you're configuring an embedded device remotely, then it makes much more sense to either:
(a) use a plain old web page served over HTTP
or
(b) serve up a Java applet with a custom dialog that then sends HTTP requests back to the device.
Both of these solutions are far more lightweight in terms of memory and bandwidth requirements. VNC is just overkill.
As far as I can see, the DMCA is unlikely to apply here since plain (non-DRM'd) ASF streams do not contain any form of copy protection.
If I remember correctly, though, Microsoft has a patent on the ASF format scheme itself. The granting of this patent in the first place was ridiculous - (thought sadly commonplace these days) - ASF is a very simple format for multiplexing video/audio/whatever over a single stream. There's nothing innovative about it.
Of course plenty of patents are issued these days for very unimaginative, uninnovative things - what makes MS's patent so unusual is that it's tantamount to patenting a file format - something that could effectively prevent otherwise legal reverse-engineering.
The author of Virtual Dub was forced to remove ASF compatibility after pressure from Microsoft regarding the patent.
Microsoft - boldly leading us back into the dark ages of incompatibility!
Depends on whether or not you view ASF stream protocols as containing copy-protection, which non-DRM'd streams certainly don't. If there's no copy-protection to "circumvent" then surely the DMCA doesn't apply?
The bigger problem for Real, I would imagine, is the (insane!) patents that Microsoft was able to obtain for the ASF protocol. Despite the fact that ASF is basically very simple, MS was able to obtain a patent, thus effectively preventing anyone from producing anything compatible with it unless they license the Windows Media Format SDK.
If there is no God, there is no Moral Authority. No reason to denounce the Holocaust. No reason to denounce the Crusades. No reason for Republicanism. I recommend a a little time in American History class.
DUDE...
If you believe that the only source of morals is some imaginary guy with a white beard that sits up in the clouds and gets pissed off when you masturbate, you are an idiot.
I don't need your god to tell me how I should behave toward other people.
A couple of other things:
Yes, a linux distro would fit
Since RAM is limited to 256K(slow) + 32K(fast), it's unlikely you're going to fit a Linux distro that can do anything meaningful. Bear in mind that the ARM7 does not have a MMU, so you'd be limited to uCLinux or something of that ilk.
Yes. In fact, there's a port of an emulator which runs NES binaries
It's not a port. It was written from scratch.
Descent is probably beyond the GBA's capabilities, since it uses arbitrarily-angled perspective-correct textured polygons, which are a fair bit harder to render on a low-end CPU (the GBA has a 16MHz ARM7 CPU).
You should see some of the stuff that's going on. There are a number of fully textured 3D engines out there, one of which actually uses Descent levels as its examples! (I linked to another in my previous post which uses the quake level 1) A good example is the Raylight [raylight.it] engine, though there are probably a dozen that I've seen (and a few proprietary, one of which I'm about halfway done writing
None of these engines do true perspective correct texturing. And yes, I'm fairly aware of the work that's going on out there - I am the author of FooN, and have also written a bunch of 3d engines for the GBA. My point was that, while DOOM/GBA is a more-or-less exact replica of the PC version, Descent/GBA is not going to look anywhere near as cool as the original.
Sorry - should have clarified - the ones I listed are all emulators for the GBA.
Sorry, but not even remotely close. You didn't even get the popular ones. There's a pretty decent list here [zophar.net], at Zophar's Domain (a pretty good dev site)
Read. Comprehend. Post.
"The ones I listed are all emulators for the GBA". Not "These are all the emulators for the GBA".
In other words, the emulators I listed are all emulators that run on the GBA, and emulate other machines.
Another thing - you mistakenly state that the GBA has a Z-buffer. WTF? As someone who claims to be developing a 3D engine for the GBA, you must be aware that the GBA most certainly doesn't have a Z buffer. It doesn't even have any polygon rendering hardware.
Sorry - should have clarified - the ones I listed are all emulators for the GBA. You can burn a flash cart containing 100's of old videogame classics, and play them on your GBA.
DOOM is already available on the GBA.
Descent is probably beyond the GBA's capabilities, since it uses arbitrarily-angled perspective-correct textured polygons, which are a fair bit harder to render on a low-end CPU (the GBA has a 16MHz ARM7 CPU).
I guess you could just flat-shade the whole thing, but it wouldn't look anywhere near as good.
NES emu
Spectrum emu
Sega Master System Emu
On the contrary. Articles have been written regarding the viability of the XBox as a server. Since they're so cheap, you could (perhaps) install BSD/Linux and use them as a web farm.
Since MS is making a loss on each box sold (they expect to make up the difference in sales of games), this, if anything, would be a damaging blow to MS.
Can someone tell me if Overlapped IO under Win32 is also zero-copy? It seems like it could be - basically you pass buffers to the OS, and the OS lets you know when it's finished with them. This works for input and output.
The other nice thing about OIO is that you don't have to populate your FDSET every time you do a select - which means if you're writing a server app with thousands of simultaneous connections, it's a whole lot faster.
Is there a Linux/BSD equivalent to this?
The viruses that have been widely propagated so far have all been fairly benign - they haven't done that much other than propagate. After all, a virus doesn't spread terribly well if it destroys its host.
Imagine what the impact would be, however, of a virus that spreads as effectively as Code Red, but formats the hard-drive after 48 hours? (Or perhaps after it's infected a certain number of machines?)
There were plenty of IIS machines that were infected for a good deal longer than 48 hours before their owners became aware of it. Hell - my boxes at home still receive hundreds of Code Red probes.
The flow of IIS vulnerabilities doesn't seem to be drying up - it may well only be a matter of time before someone writes something that's really malicious. Growing complacent because the computer press has cried wolf so many times is incredibly dangerous.
I don't read this as implying that the DMCA requires anything... just that a person is legally permitted to reverse engineer a protocol/format in order to acheive interoperability.
Knowing Microsoft, their next step will be to implement a completely new filesystem, encourage (force) everyone to upgrade, and protect it with encryption (if they claim that the encryption is for protection of a user's intellectual property, then perhaps the DMCA would have more teeth in this situation), and/or patents (somewhat akin to what they did with ASF).
Microsoft - boldly leading us back into the dark ages of incompatibility.