You have a point for the bandwidth constrained mediums, like satellite tv, cable tv, and even broadcast digital TV.
But, most recently encoded DVDs do a pretty good job, and the artifacts are at a minimum. The bandwidth available per pixel on a DVD is much higher than any of those other mediums.
But, the bandwidth for theater projection is much higher. The article didn't have any details.. but if it's like the systems they are using elsewhere for digital projection, each film takes terabytes of storage, and they are not using MPEG for compression. They have a pretty high standard for quality.
The only thing I have found questionable is the resolution.. the recent star wars films have used something on the order of 1080P, which is great for home theater use, but filling a 100' screen, those pixels get pretty big.
I can see his point about possible exploits for two factor authentication schemes.
But, can't you mitigate Man in Middle attacks by securing the transport? If you used SSL (or even IPSec), with client certificates, you could authenticate the user's session based on his certificate. Then, using a strong authentication for each transaction (matched with the user identity from the SSL Cert) would provide a fairly strong structure.
Of course, that wouldn't necessarily stop a trojan running on the client machine. But, what would?
In any case, each of these security measures would raise the bar for attackers / phishers. So, I don't think they should be dismissed because they don't solve 100% of all theoretical problems.
> explicitly exclude user-to-user chat sessions from the privacy rights an AIM user gives up to AOL.
That's an improvement. But, wouldn't it be better (from a user rights and privacy perspective) to explicitly state the areas they DO take ownership of your data in, rather than only excluding this one area? The default case should be that they don't own your data. With excluding only AIM, they still leave the default case for all other services to be that AOL owns your data.
It's sort of like opt-in vs. opt-out. I prefer that anyone using my personal information or data be required to get my explicit permission to use it, rather than requiring me to contact each and ask them to not use it.
I don't know if he is just making lemonade from the SCO lemons, or if he really has a point..
The negative way to look at the SCO thing is that it's just the beginning of a huge wave of patent infringement lawsuits that all the big boys and many little patent leaches are positioning themselves for.
The positive spin would be that Linux withstood a well funded / backed instance of that strategy, and people didn't stop moving to Linux while the lawsuit was active. So, this would imply that Linux can survive and even flourish in the face of the inevitable lawsuits.
I'm not sure which I actually believe. I think our porous patent system is transferring all the burden they should be taking unto the court system (which has been ill equipped to handle complex technical cases in the past).
In general, that's not the way most owners feel about people using their work without paying royalties (and rightly so..).
I just wonder why the people doing this excellent project did not put a bit of a twist on the concept to make it their own. Why not set it in the same universe as Privateer, but with a unique story line?
They would be on much better ground with a derivative work then with a complete copy.
> Change your password regularly. Don't make it obvious. Log out of the system when you're done
That's fine for making general users more secure..
What he's talking about is more to do with making admin types more skeptical / less polite. The common 'exploits' that Mitnick, and many others, have done is to learn enough about a target company's practices, and talk your way into getting privileges that employees get.
e.g. call the phone company's internal support line, talk the talk of the phone technician, and get them to change your account, give you information, etc.
Or, call a corporate support line complaining of problems with your dialup access to the corporate network. Get them to reset "your" password for you, and you're in the network. 99% of the calls they get are legitimate employees, probably with the same old problems. If you sound like one of those normal employees, the support people will work hard to get you access to the network.
> I say this because as a commercial developer I know plenty of managers who won't let me use Open Source on their projects because they think all Open Source has a viral license such as GPL.
Okay... and what's the problem with that?
That sounds like a commercial product, which wants to engulf open source code but not contribute anything back. I really don't care if they can't use it, as that bargain only benefits them, noone else. If they don't feel they can contribute back, then they need to build their own (presumably, paying you to do it). You're asking a lot of your fellow developers to think that they should license their work with a BSD-like license. So, the benefit flows only away from them.
This is not to say I think GPL is the only way to go.. I work for a software company which does not play in the GPL game. But, we don't benefit from GPL'd code. That's fine with me.
I would like to see Firefox enable some more dynamic controls for pages that I load. There are several technologies that I want to use most of the time, but I would like the ability to override.
Such as: - stop/disable animated gifs. If I find a site annoying, let me stop the damn animated images. These really suck when I'm trying to read a long article, and a monkey is jumping around in an image at the border of the text.
- disable audio output. A www site should almost never be able to output audio. The default should be mute, perhaps with a popup saying "this site wants the speaker. allow it?".
- disable javascript for a site. This should take care of the "floaters", and a lot of other annoying js behavior.
> This is by no means dead. When the entertainment industry can't foist something on you by the backdoor they use plan B: Ask the senate for a nice bit of special interest legislation.
Actually, this was the back door.
Congress told them to fuck off when they went looking for legislation.
Then, they went to the FCC, and Michael Powell was more than willing to bend over for big business. But, that seems to be standard operating procedure for the current administration. They talk "free markets", but in practice there are way too many gifts to big business. (letting polluters out of environmental enforcements, letting Microsoft out of antitrust enforcements, etc.) Locking the little guys out of the market and perpetuating the market for the big guys.
Yes, I didn't understand the title.. it had nothing to do with the story that was linked. The story was pretty positive on Netflix, it wasn't predicting that they would get "left in the dust" or anything like that.
But, editorializing the posting is pretty common here at/. But, normally it at least has some relation to the linked content..
> So... how exactly are they going to ship patches in the case of a security issue?
That's a good point. Depending on how this is implemented, a security fix could be a big problem. If they used an ASIC on the NIC card, you might be looking at a swap-out upgrade.
If they use something that is firmware upgradable, it generally wouldn't have the performance of a true hardware solution.
Although, TCP/IP is a pretty well established standard, so I think security issues in individual packet processing are unlikely. There is not a lot of security happening in TCP/IP.. it's known to be insecure. The complex security operations are happening at other layers (an IPSec tunnel, or application-specific security).
If a problem was found in the network offload hardware, you would just fall back to a standard processing scenario - where all the network processing is done on the host CPU.
Probably not.. But, all that means is that IPv6 processing will not benefit from the hardware on the card. So, you'll be no worse off than you are today, with a card that does no offload.
It's sort of like Intel's current Gig-E cards, they offer TCP checksum offload. But, your driver/stack needs to take advantage of this feature. If you use an old driver that doesn't use it, everything still works fine, but your CPU is doing a bit more work.
If/when IPv6 becomes common, Intel will most likely have TCP Offload support implemented quickly.
That is true for the recording piece.. Digital TV broadcasts are already MPEG2 encoded, so you just write it to disk.
For playback, you're making a big assumption to say you can just send it via firewire. Very few TVs have integrated HD tuners and firewire. Today, the best option is to decode/display on the PC.
Unfortunately, Apple does not have an API for MPEG2 acceleration (equivalent to DxVA in Windows and XvMC in Linux). So, you cannot currently benefit from the hardware in your Mac. Hopefully Apple will remedy this situation in 'Tiger'.
All ATI Radeon cards have hardware offload support.
Nvidia GeForce4 MX, GeForce FX, and newer cards support MPEG2 accel. All the others did not.
Did you try the original Shuttle SFF "Cubes"? They were loud as hell.
I have never seen an x86 SFF machine that didn't have a fan. Even with a heat pipe, they pump out way too much heat, you need some air movement to keep the heat sink at the end of the pipe cooled. Although, if you put a VIA C3 or some other very low power/heat CPU in it you could get by without a fan.
In any case, the original point is correct. Even with fan speed controls and heat pipes, the SFF systems are still loud compared to a cube. The SFF systems also have a fan in the power supply, which is not quiet.
The Cube, on the other hand, has ZERO fans. It just has some large heat sinks, and an air channel rising through the center of the Cube. The only thing that makes noise is the hard drive. I replaced the drive in my Cube with a Seagate Barracuda, which can't be heard unless you press your ear right up to the vent on the top of the Cube. So, while the shuttles may have improved on the loud fans in their early models, there is no way they compare to the fanless Cubes.
> If the Mac Mini sells well, everyone will copy the idea. If not, it will disappear like the Cube and no one will ever build anything like it again.
The PowerMac G4 Cube kicked off a whole industry of PCs. It was the reason the Small Form Factor (SFF) PCs, the most successful of which are from Shuttle. When they first came out (not too long after the Mac Cube) people were calling them PC Cubes.
Of course the SFF PCs are nothing like the G4 Cube in its simple, quiet, elegant design. I guess the SFF box was the best they could do when accomodating PC requirements (HOT running CPU needed a huge heat sink + fan, internal ATX power supply to meet the high wattage requirements, and PCI/AGP slots to satisfy PC tweakers).
If the PC manufacturers do copy the mini, expect it to be another design full of compromises and lacking the style of a Mac.
Premium digital cables are a rip-off. Just go to a discount electronics place, or even eBay to get cheap/decent cables.
In the analog world, a logical case could be made for high quality cables because any interference would be propogated through the system and hurt audio quality.
In digital cables, it's just ones and zeros.. As long as the digital data is there, it's not any better or worse regardless of the type of cable.
If your digital cable is not working well, it should be very obvious in the audio/video output.
Obviously, this is not a C portability issue. It's an issue with proprietary GUI APIs.
If it used some standard GUI abstraction layer, it would have been a simple port (as seen with the X11 version, which was easily ported to MacOS+X11 -- how's that for C portability?). But, the port to a different GUI would take much more effort. Unfortunately, the developer resources just aren't there for a native UI port (most of the relevant developers gravitated over to the MacOS X only, Java based, NeoOfficeJ instead).
Viewing HDTV is kind of a bad example for this. HDTV is received as a 20Mbps MPEG2 stream. This can easily be passed through a cardbus slot, and probably through an old standard PCMCIA slot.
The only time it becomes bandwidth intensive is after the MPEG2 is decoded on the CPU, you need good AGP bus bandwidth to send the 1920x1080i video to the display.
This sounds like an interesting use of P2P networking. But, it makes your broadcast very non-deterministic. Listeners will get a decent experience iff several factors are correct.
Multicasting would be a much better solution for IP broadcasting, and it has been around for a long time. But, it has never really hit prime time. With multicasting, you need only enough bandwidth for your stream. It is passed through the internet as needed - as users connect to the broadcast & subscribe to the multicast stream, the data is mirrored onto the necessary links. But, any link should have a maximum of one instance of the stream.
In theory multicasting sounds great, and there have been some very interesting implementations, particularly on Internet2. But, it never seems to hit critical mass.
Slashdot Mirror
You have a point for the bandwidth constrained mediums, like satellite tv, cable tv, and even broadcast digital TV.
But, most recently encoded DVDs do a pretty good job, and the artifacts are at a minimum. The bandwidth available per pixel on a DVD is much higher than any of those other mediums.
But, the bandwidth for theater projection is much higher. The article didn't have any details.. but if it's like the systems they are using elsewhere for digital projection, each film takes terabytes of storage, and they are not using MPEG for compression. They have a pretty high standard for quality.
The only thing I have found questionable is the resolution.. the recent star wars films have used something on the order of 1080P, which is great for home theater use, but filling a 100' screen, those pixels get pretty big.
I can see his point about possible exploits for two factor authentication schemes.
But, can't you mitigate Man in Middle attacks by securing the transport? If you used SSL (or even IPSec), with client certificates, you could authenticate the user's session based on his certificate. Then, using a strong authentication for each transaction (matched with the user identity from the SSL Cert) would provide a fairly strong structure.
Of course, that wouldn't necessarily stop a trojan running on the client machine. But, what would?
In any case, each of these security measures would raise the bar for attackers / phishers. So, I don't think they should be dismissed because they don't solve 100% of all theoretical problems.
> explicitly exclude user-to-user chat sessions from the privacy rights an AIM user gives up to AOL.
That's an improvement. But, wouldn't it be better (from a user rights and privacy perspective) to explicitly state the areas they DO take ownership of your data in, rather than only excluding this one area? The default case should be that they don't own your data. With excluding only AIM, they still leave the default case for all other services to be that AOL owns your data.
It's sort of like opt-in vs. opt-out. I prefer that anyone using my personal information or data be required to get my explicit permission to use it, rather than requiring me to contact each and ask them to not use it.
I don't know if he is just making lemonade from the SCO lemons, or if he really has a point..
The negative way to look at the SCO thing is that it's just the beginning of a huge wave of patent infringement lawsuits that all the big boys and many little patent leaches are positioning themselves for.
The positive spin would be that Linux withstood a well funded / backed instance of that strategy, and people didn't stop moving to Linux while the lawsuit was active. So, this would imply that Linux can survive and even flourish in the face of the inevitable lawsuits.
I'm not sure which I actually believe. I think our porous patent system is transferring all the burden they should be taking unto the court system (which has been ill equipped to handle complex technical cases in the past).
In general, that's not the way most owners feel about people using their work without paying royalties (and rightly so..).
I just wonder why the people doing this excellent project did not put a bit of a twist on the concept to make it their own. Why not set it in the same universe as Privateer, but with a unique story line?
They would be on much better ground with a derivative work then with a complete copy.
> Change your password regularly. Don't make it obvious. Log out of the system when you're done
That's fine for making general users more secure..
What he's talking about is more to do with making admin types more skeptical / less polite. The common 'exploits' that Mitnick, and many others, have done is to learn enough about a target company's practices, and talk your way into getting privileges that employees get.
e.g. call the phone company's internal support line, talk the talk of the phone technician, and get them to change your account, give you information, etc.
Or, call a corporate support line complaining of problems with your dialup access to the corporate network. Get them to reset "your" password for you, and you're in the network. 99% of the calls they get are legitimate employees, probably with the same old problems. If you sound like one of those normal employees, the support people will work hard to get you access to the network.
> our CEO is a self proclaimed salesman.
Yes, but he doesn't really grasp his place in the world until he refers to himself as a "salesdroid". Salesman implies too much respect for that role.
> I say this because as a commercial developer I know plenty of managers who won't let me use Open Source on their projects because they think all Open Source has a viral license such as GPL.
Okay... and what's the problem with that?
That sounds like a commercial product, which wants to engulf open source code but not contribute anything back. I really don't care if they can't use it, as that bargain only benefits them, noone else. If they don't feel they can contribute back, then they need to build their own (presumably, paying you to do it). You're asking a lot of your fellow developers to think that they should license their work with a BSD-like license. So, the benefit flows only away from them.
This is not to say I think GPL is the only way to go.. I work for a software company which does not play in the GPL game. But, we don't benefit from GPL'd code. That's fine with me.
I would like to see Firefox enable some more dynamic controls for pages that I load. There are several technologies that I want to use most of the time, but I would like the ability to override.
Such as:
- stop/disable animated gifs. If I find a site annoying, let me stop the damn animated images. These really suck when I'm trying to read a long article, and a monkey is jumping around in an image at the border of the text.
- disable audio output. A www site should almost never be able to output audio. The default should be mute, perhaps with a popup saying "this site wants the speaker. allow it?".
- disable javascript for a site. This should take care of the "floaters", and a lot of other annoying js behavior.
Yes... I didn't read my own link..
Powell was nominated to the commission by Clinton.
But, he was appointed commissioner by Dubya.
> I hate to interrupt a Bush-bashing session with facts, but Powell was appointed by the previous administration
a phy.html
Where do you get your "facts", Fox News?
Powell was a Dubya appointee.
http://www.fcc.gov/commissioners/powell/mkp_biogr
> This is by no means dead. When the entertainment industry can't foist something on you by the backdoor they use plan B: Ask the senate for a nice bit of special interest legislation.
Actually, this was the back door.
Congress told them to fuck off when they went looking for legislation.
Then, they went to the FCC, and Michael Powell was more than willing to bend over for big business. But, that seems to be standard operating procedure for the current administration. They talk "free markets", but in practice there are way too many gifts to big business. (letting polluters out of environmental enforcements, letting Microsoft out of antitrust enforcements, etc.) Locking the little guys out of the market and perpetuating the market for the big guys.
Yes, I didn't understand the title.. it had nothing to do with the story that was linked. The story was pretty positive on Netflix, it wasn't predicting that they would get "left in the dust" or anything like that.
/. But, normally it at least has some relation to the linked content..
But, editorializing the posting is pretty common here at
> So... how exactly are they going to ship patches in the case of a security issue?
That's a good point. Depending on how this is implemented, a security fix could be a big problem. If they used an ASIC on the NIC card, you might be looking at a swap-out upgrade.
If they use something that is firmware upgradable, it generally wouldn't have the performance of a true hardware solution.
Although, TCP/IP is a pretty well established standard, so I think security issues in individual packet processing are unlikely. There is not a lot of security happening in TCP/IP.. it's known to be insecure. The complex security operations are happening at other layers (an IPSec tunnel, or application-specific security).
If a problem was found in the network offload hardware, you would just fall back to a standard processing scenario - where all the network processing is done on the host CPU.
Probably not.. But, all that means is that IPv6 processing will not benefit from the hardware on the card. So, you'll be no worse off than you are today, with a card that does no offload.
It's sort of like Intel's current Gig-E cards, they offer TCP checksum offload. But, your driver/stack needs to take advantage of this feature. If you use an old driver that doesn't use it, everything still works fine, but your CPU is doing a bit more work.
If/when IPv6 becomes common, Intel will most likely have TCP Offload support implemented quickly.
That is true for the recording piece.. Digital TV broadcasts are already MPEG2 encoded, so you just write it to disk.
For playback, you're making a big assumption to say you can just send it via firewire. Very few TVs have integrated HD tuners and firewire. Today, the best option is to decode/display on the PC.
Unfortunately, Apple does not have an API for MPEG2 acceleration (equivalent to DxVA in Windows and XvMC in Linux). So, you cannot currently benefit from the hardware in your Mac. Hopefully Apple will remedy this situation in 'Tiger'.
All ATI Radeon cards have hardware offload support.
Nvidia GeForce4 MX, GeForce FX, and newer cards support MPEG2 accel. All the others did not.
Did you try the original Shuttle SFF "Cubes"? They were loud as hell.
I have never seen an x86 SFF machine that didn't have a fan. Even with a heat pipe, they pump out way too much heat, you need some air movement to keep the heat sink at the end of the pipe cooled. Although, if you put a VIA C3 or some other very low power/heat CPU in it you could get by without a fan.
In any case, the original point is correct. Even with fan speed controls and heat pipes, the SFF systems are still loud compared to a cube. The SFF systems also have a fan in the power supply, which is not quiet.
The Cube, on the other hand, has ZERO fans. It just has some large heat sinks, and an air channel rising through the center of the Cube. The only thing that makes noise is the hard drive. I replaced the drive in my Cube with a Seagate Barracuda, which can't be heard unless you press your ear right up to the vent on the top of the Cube. So, while the shuttles may have improved on the loud fans in their early models, there is no way they compare to the fanless Cubes.
> If the Mac Mini sells well, everyone will copy the idea. If not, it will disappear like the Cube and no one will ever build anything like it again.
The PowerMac G4 Cube kicked off a whole industry of PCs. It was the reason the Small Form Factor (SFF) PCs, the most successful of which are from Shuttle. When they first came out (not too long after the Mac Cube) people were calling them PC Cubes.
Of course the SFF PCs are nothing like the G4 Cube in its simple, quiet, elegant design. I guess the SFF box was the best they could do when accomodating PC requirements (HOT running CPU needed a huge heat sink + fan, internal ATX power supply to meet the high wattage requirements, and PCI/AGP slots to satisfy PC tweakers).
If the PC manufacturers do copy the mini, expect it to be another design full of compromises and lacking the style of a Mac.
I did a search for "Linux" to try out the site. It came up with an amusing reference from an episode of NCIS.
...
" One man's linux is another's Os/2. (Laughs) I hear that."
NCIS
DVI already has DRM in most TV's. It's called HDCP, and almost all HDTV STBs and TVs support it.
That's the same thing done in HDMI.
Premium digital cables are a rip-off. Just go to a discount electronics place, or even eBay to get cheap/decent cables.
In the analog world, a logical case could be made for high quality cables because any interference would be propogated through the system and hurt audio quality.
In digital cables, it's just ones and zeros.. As long as the digital data is there, it's not any better or worse regardless of the type of cable.
If your digital cable is not working well, it should be very obvious in the audio/video output.
WTF?
Obviously, this is not a C portability issue. It's an issue with proprietary GUI APIs.
If it used some standard GUI abstraction layer, it would have been a simple port (as seen with the X11 version, which was easily ported to MacOS+X11 -- how's that for C portability?). But, the port to a different GUI would take much more effort. Unfortunately, the developer resources just aren't there for a native UI port (most of the relevant developers gravitated over to the MacOS X only, Java based, NeoOfficeJ instead).
Viewing HDTV is kind of a bad example for this. HDTV is received as a 20Mbps MPEG2 stream. This can easily be passed through a cardbus slot, and probably through an old standard PCMCIA slot.
The only time it becomes bandwidth intensive is after the MPEG2 is decoded on the CPU, you need good AGP bus bandwidth to send the 1920x1080i video to the display.
This sounds like an interesting use of P2P networking. But, it makes your broadcast very non-deterministic. Listeners will get a decent experience iff several factors are correct.
Multicasting would be a much better solution for IP broadcasting, and it has been around for a long time. But, it has never really hit prime time. With multicasting, you need only enough bandwidth for your stream. It is passed through the internet as needed - as users connect to the broadcast & subscribe to the multicast stream, the data is mirrored onto the necessary links. But, any link should have a maximum of one instance of the stream.
In theory multicasting sounds great, and there have been some very interesting implementations, particularly on Internet2. But, it never seems to hit critical mass.